Иногда он хватается, иногда это сделать сложно - вместо этого клик приходится на ссылку или выделяется текст. Насколько я понимаю, сложность появляется после того, как пролистал горизонтально и вернулся
Сообщение об ошибке, которое сопровождает перезагрузку страницы
Интересно, но не смог дочитать. На iPhone страница часто вылетает с ошибкой. На параграфе про ооп против фп становится совсем уж тяжко - 30 секунд и пока. При этом каждый раз заново скроллить вниз трудно - не ухватывается скроллбар.
I tend to stick to printf debugging because Rust debuggers are still pretty bad, so that's a wash for me. But in languages with good debugger support, I can see how this style might be a bit of a pain.
Так что тут вряд ли написано с иронией - прямо сказано, что дебаггер плюсов лучше
Как замена блокноту он уже хорош, т.к. поддерживает интеграцию с tree sitter и LSP «из коробки». Как IDE я его пока не пытался использовать - всё равно долго с настройкой возиться.
Плагинов нет, т.к. системы плагинов пока в принципе нет. Я его запускаю из-под Zellij, к ней плагины есть
Как замена блокноту он уже хорош, т.к. поддерживает интеграцию с tree sitter и LSP «из коробки». Как IDE я его пока не пытался использовать - всё равно долго с настройкой возиться.
Плагинов нет, т.к. системы плагинов пока в принципе нет. Я его запускаю из-под Zellij, к ней плагины есть
Возврат в режим редактирования (esc i) делает нередактируемой строку до курсора. Это раздражает - неудобно и из vim такое поведение давно убрали
Не работают home и end клавиши. esc $ и esc 0 это круто, конечно, но можно пожалуйста home и end тоже
Не стирается символ переноса строки. Надо жать esc j J, чтобы убрать пустую строку
А ещё после перехода на helix надо держать в голове 3 разных vi-like системы хоткеев: как в vi (с проблемами выше), как в vim/neovim (без проблем выше), как в helix (select->edit вместо edit->select, мне так удобнее)
может быть есть где-то плагин для zsh, где эти проблемы vi-mode пофиксили и там хоткеи хотя бы как в vim?
Датумы удобнее рассматривать как эллипсоидные проекции или модели изогнутой поверхности планеты, на которых можно проводить позиционные измерения для определения точного местоположения.
Таки что вы хотели тут сказать? Что датум - это проекция? Нет, датум это не проекция…
Из-за неидеальной сферической формы планеты и того, что датумы используют разные базы данных, может происходить так называемый сдвиг.
Какие базы данных? Почему сдвиг «так называемый»? Вы хотели написать «в разных системах координат одна и та же точка имеет разные координаты»? Это очевидно как бы…
Таким образом, различия из-за смещения датума между WGS-84 и PZ-90 по большей части можно считать минимальными.
А можно и не считать… Вы пишете про системы координат, используемые в ГНСС, но ни слова про прямоугольные координаты XYZ. Хотя по приведённой вами же ссылке раздел систем координат начинается именно с них
к широте и долготе добавляются случайные смещения в диапазоне от 50 до 500 метров
Широта и долгота это углы, они не измеряются в метрах
У вас интересная статья получилась, темя хорошая, но выкладки по геодезии непонятны совершенно, все термины в кучу, солёное сравнивается с мягким. Хотя вы ссылаетесь на более-менее адекватные материалы. Возможно, мне просто не хватает компетенции, чтобы эти выкладки понять, тогда наверное стоило упростить язык
Zotero в libreoffice поддерживается и работает, на мой взгляд, стабильнее, чем в ворде.
Но ещё удобнее для меня оказалось Zotero с плагинами для экспорта в Bibtex + вёрстка в LateX + синхронизация библиотеки Zotero по WebDAV с Яндекс диском (планирую менять на self-hosted Nextcloud).
По поводу остального MS Office несомненно удобнее для работы с документами, т.к. для этого в нём не надо читать тонны документации и мануалов. Но лично для меня, например, оказалось весьма удобным погрузиться в документацию и
За это отвечает latex:
автоматическая генерация оглавления по шаблону заголовков с вложенной нумерацией
Заменил spreadsheets на Rstudio (в моей предметной области это возможно, но совершенно точно не во всех так)
встроенное редактирование графиков и диаграмм, редактирование ячеек таблиц включая выравнивание содержимого
XeteX использует системные шрифты:
шрифт Palatino Linotype
А вот с этим ничего не придумал, к сожалению:
режим рецензии
Я это написал не ради контраргумента к вашей позиции, я с ней согласен. Хотел проиллюстрировать, что удобная замена этих сервисов вполне возможна, главное определиться чем именно вы хотите расплачиваться за life-as-service, как вы выразились выше. Если не готовы платить деньгами - можно расплатиться временем на изучение технологий, ну то есть тоже деньгами, если за это время вам никто не платит (и немножко деньгами на свою сетевую мини-инфраструктуру).
Если заменить перевод "тепловые карты" на "цветовые шкалы", то станет гораздо понятнее, о чем речь вообще. Map в слове heatmap не означает карта, а скорее означает отображение.
То, что все переводят "heatmap" как теплокарта, не значит, что стоит продолжать так делать. Почти всегда это неуместно, так как слово map в английском более многозначно, чем русское карта.
Давайте я попробую внести ясность, раскрыв смысл нескольких терминов.
Геодезическая широта - угол между нормалью к эллипсоиду и плоскостью экватора. Геодезическая долгота - двугранный угол между плоскостями меридиана и нулевого меридиана.
WGS-84 - это наименование эллипсоида, который описывается определёнными параметрами (SPHEROID["WGS_1984",6378137.0,298.257223563]] из вашего примера). Также WGS-84 это наименование датума. Датум - это то, как этот эллипсоид расположен в теле Земли (грубое упрощение). Когда вы просите любую систему рендеринга нарисовать вам данные в "географической системе координат", вы получаете изображение, которое выглядит как квадратная цилиндрическая проекция. В вашем SHP-файле X и Y это и есть широта и долгота, о чём говорит строка с описанием проекции.
Когда Яндекс показывает вам значения 56.643434, 37.671169, то скорее всего вам показывают исходные данные - геодезическую широту и долготу точки, на которую вы ткнули на карте. Скорее всего это действительно EPSG:4326, но не факт. Широта и долгота это не "всегда одно и то же". Если используется другой датум и другая референц-поверхность (эллипсоид с другими параметрами или сфера), то и значения широт и долгот будут другими.
Отдельно про разницу Меркатора и Веб-Меркатора (в интернете об этом много, но каждый новый раз не лишний)
Проекция Меркатора - это уравнения перехода от географических координат к плоским прямоугольным. Есть уравнения проекции Меркатора для сферы, есть для эллипсоида. Проекция Меркатора для эллипсоида WGS-84 это EPSG:3395 (WGS 84 / World Mercator) и только она. Судя по всему, её и использует Яндекс.
Проекция Меркатора для сферы это, например, ESRI:53004, но в каталоге есть и другие - для разных параметров сферы. Чтобы честно получить проекцию для сферы надо сначала перевести геодезические координаты в геоцентрические. Разница в том, что геодезическая широта - это угол между нормалью к поверхности и плоскостью экватора. А геоцентрическая широта - это угол между радиус-вектором и плоскостью экватора. На сфере нормаль и радус-вектор совпадают, а на эллипсоиде не совпадают. Поэтому чтобы корректно построить проекцию Меркатора для сферы, если у вас есть данные в датуме WGS-84, надо их сначала перевести в геоцентрические, и только потом выполнять проецирование на плоскость.
В веб-меркаторе (EPSG:3857) происходит следующий трюк: координаты используются геодезические на эллипсоиде, а формулы используются для геоцентрических координат на сфере. Из-за этого раньше возникала всяческая путаница и неразбериха, когда люди пытались одновременно использовать EPSG:3395 и веб-меркатор. Если пытаться просто совместить две карты в этих проекциях без дополнительных преобразований, то ничего не получится, всё разъедется.
Поэтому мой ответ на ваш вопрос "Для каких задач мне критично знать, что эти числа получены из Web Mercator?": для любых. Если вы знаете, что у вас данные в проекции веб-меркатора, вы просто указываете в метаданных код проекции 3857 и ГИС-ПО делает все нужные преобразования за вас. Если вы не знаете - у вас разные данные "разъедутся", и довольно сильно.
Не согласен с тем, что веб-меркатор какой-то неточный. Картографическая проекция не может быть точной или не точной. Картографическая проекция это взаимно-однозначное соответствие между географическими координатами и плоскими. Это условие для веб-меркатора сохраняется.
Неточными могут быть измерения, выполненные в этой проекции. Поэтому не надо делать в ней измерений - никакая проекция Меркатора для этого не предназначена, там очень большие искажения длин и площадей.
Неточным может быть преобразование координат - там используются разложения в ряды, там есть ограничения по точности со стороны арифметики с плавающей точкой. Но эти тонкости касаются уже геодезистов и тех, кто с кадастром рабоатет. Если вам надо плюс-минус метр, встроенные в ГИС-ПО преобразования Гельмерта "по умолчанию" вам подойдут.
Не ломается, но просто тормозит (i7-7700HQ, 20гб RAM, файлик на ~65 страниц с большим числом стилей, иллюстраций, внутренними ссылками, ссылками в Zotero)
Большинство ресурсных спутников (те, которые поставляют высокодетальные снимки на большие покрытия относятся к этой категории) летает по солнечно-синхронной орбите. Она устроена таким образом, что местное время в подспутниковой точке всё время одинаковое (ну, почти одинаковое). Чтобы этого достичь нужна высота ~900км и отрицательное наклонение орбиты
Приведённая модель это довольно сильное упрощение того, что на самом деле происходит. В действительности положение внутритропической зоны конвергенции (это то, что между двумя "экваториальными" ячейками на вашей схеме) имеет ярко выраженную сезонную динамику, особенно на африканском континенте. Собственно, в эту сезонную динамику существенный вклад вносят и характер подстилающей поверхности (растительность/пустыня), и морские течения. Если бы Сахара не была пустыней, то сезонная динамика ВЗК была бы иной (и в Сахаре выпадало бы больше осадков).
Поэтому утверждение, что Сахара является пустыней вследствие глобальной циркуляции атмосферы верно лишь отчасти. Вторая часть заключается в том, что в процессе опустынивания был запущен процесс с положительной обратной связью, который привёл к текущему положению системы. А текущее положение является относительно стабильным, в нём глобальная циркуляция и региональные особенности "поддерживают" друг друга.
Вроде как раз арч и не получил. Поскольку атака была на систему сборки и на арчевской не воспроизвелась. Плюс, в стабильную версию оно вроде как и не попало. https://archlinux.org/news/the-xz-package-has-been-backdoored/
В исходниках есть функция, которая предназначена для подмены названия в буферах бит. Т.е. автор по крайней мере заложил возможность не только в JSON подменять https://github.com/brycebostwick/FixTheGulf/blob/b40ed628a0d4b2e7d150d33c46cfe5b8272b2a7a/gulf.js#L134
Просто крашится во время работы.
iOS 17.6.1
Скроллбар на iOS даже с виброоткликом. Пользуюсь, чтобы быстро прокручивать страницы.
Иногда он хватается, иногда это сделать сложно - вместо этого клик приходится на ссылку или выделяется текст. Насколько я понимаю, сложность появляется после того, как пролистал горизонтально и вернулся
Интересно, но не смог дочитать. На iPhone страница часто вылетает с ошибкой. На параграфе про ооп против фп становится совсем уж тяжко - 30 секунд и пока. При этом каждый раз заново скроллить вниз трудно - не ухватывается скроллбар.
Вот этот тезис из начала треда не совсем верен:
Из другой статьи автора:
Так что тут вряд ли написано с иронией - прямо сказано, что дебаггер плюсов лучше
Как замена блокноту он уже хорош, т.к. поддерживает интеграцию с tree sitter и LSP «из коробки». Как IDE я его пока не пытался использовать - всё равно долго с настройкой возиться.
Плагинов нет, т.к. системы плагинов пока в принципе нет. Я его запускаю из-под Zellij, к ней плагины есть
Как замена блокноту он уже хорош, т.к. поддерживает интеграцию с tree sitter и LSP «из коробки». Как IDE я его пока не пытался использовать - всё равно долго с настройкой возиться.
Плагинов нет, т.к. системы плагинов пока в принципе нет. Я его запускаю из-под Zellij, к ней плагины есть
Полностью согласен. Но и он не идеален
Возврат в режим редактирования (esc i) делает нередактируемой строку до курсора. Это раздражает - неудобно и из vim такое поведение давно убрали
Не работают home и end клавиши. esc $ и esc 0 это круто, конечно, но можно пожалуйста home и end тоже
Не стирается символ переноса строки. Надо жать esc j J, чтобы убрать пустую строку
А ещё после перехода на helix надо держать в голове 3 разных vi-like системы хоткеев: как в vi (с проблемами выше), как в vim/neovim (без проблем выше), как в helix (select->edit вместо edit->select, мне так удобнее)
может быть есть где-то плагин для zsh, где эти проблемы vi-mode пофиксили и там хоткеи хотя бы как в vim?
У вас карты в конце зеркально отражены. Это как-то связано с особенностями реализации свёрток или случайно получилось?
Кажется, это можно перевести как «порог» или «пороговое значение»
Таки что вы хотели тут сказать? Что датум - это проекция? Нет, датум это не проекция…
Какие базы данных? Почему сдвиг «так называемый»? Вы хотели написать «в разных системах координат одна и та же точка имеет разные координаты»? Это очевидно как бы…
А можно и не считать… Вы пишете про системы координат, используемые в ГНСС, но ни слова про прямоугольные координаты XYZ. Хотя по приведённой вами же ссылке раздел систем координат начинается именно с них
Широта и долгота это углы, они не измеряются в метрах
У вас интересная статья получилась, темя хорошая, но выкладки по геодезии непонятны совершенно, все термины в кучу, солёное сравнивается с мягким. Хотя вы ссылаетесь на более-менее адекватные материалы. Возможно, мне просто не хватает компетенции, чтобы эти выкладки понять, тогда наверное стоило упростить язык
Какая это у вас тема стоит?
Zotero в libreoffice поддерживается и работает, на мой взгляд, стабильнее, чем в ворде.
Но ещё удобнее для меня оказалось Zotero с плагинами для экспорта в Bibtex + вёрстка в LateX + синхронизация библиотеки Zotero по WebDAV с Яндекс диском (планирую менять на self-hosted Nextcloud).
По поводу остального MS Office несомненно удобнее для работы с документами, т.к. для этого в нём не надо читать тонны документации и мануалов. Но лично для меня, например, оказалось весьма удобным погрузиться в документацию и
За это отвечает latex:
Заменил spreadsheets на Rstudio (в моей предметной области это возможно, но совершенно точно не во всех так)
XeteX использует системные шрифты:
А вот с этим ничего не придумал, к сожалению:
Я это написал не ради контраргумента к вашей позиции, я с ней согласен. Хотел проиллюстрировать, что удобная замена этих сервисов вполне возможна, главное определиться чем именно вы хотите расплачиваться за life-as-service, как вы выразились выше. Если не готовы платить деньгами - можно расплатиться временем на изучение технологий, ну то есть тоже деньгами, если за это время вам никто не платит (и немножко деньгами на свою сетевую мини-инфраструктуру).
UPD:
Collabora поддерживает интеграцию с Zotero (https://www.collaboraoffice.com/collabora-online/how-to-manage-bibliographic-data-with-zotero-and-collabora-online/) Так что в целом, все ваши требования open-source для self-hosted решений формально удовлетворяет. Но будет не очень удобно, немного тупить, меньше функций, интеграция похуже и потребует навыков сетевого администрирования для развёртывания инфраструктуры.
POSIX спецификация требует, чтобы cd был бинарником. И в этом моменте linux отступает от спецификации ради удобства. Пруф
Если заменить перевод "тепловые карты" на "цветовые шкалы", то станет гораздо понятнее, о чем речь вообще. Map в слове heatmap не означает карта, а скорее означает отображение.
То, что все переводят "heatmap" как теплокарта, не значит, что стоит продолжать так делать. Почти всегда это неуместно, так как слово map в английском более многозначно, чем русское карта.
Давайте я попробую внести ясность, раскрыв смысл нескольких терминов.
Геодезическая широта - угол между нормалью к эллипсоиду и плоскостью экватора. Геодезическая долгота - двугранный угол между плоскостями меридиана и нулевого меридиана.
WGS-84 - это наименование эллипсоида, который описывается определёнными параметрами (
SPHEROID["WGS_1984",6378137.0,298.257223563]]из вашего примера). Также WGS-84 это наименование датума. Датум - это то, как этот эллипсоид расположен в теле Земли (грубое упрощение). Когда вы просите любую систему рендеринга нарисовать вам данные в "географической системе координат", вы получаете изображение, которое выглядит как квадратная цилиндрическая проекция. В вашем SHP-файле X и Y это и есть широта и долгота, о чём говорит строка с описанием проекции.Когда Яндекс показывает вам значения 56.643434, 37.671169, то скорее всего вам показывают исходные данные - геодезическую широту и долготу точки, на которую вы ткнули на карте. Скорее всего это действительно
EPSG:4326, но не факт. Широта и долгота это не "всегда одно и то же". Если используется другой датум и другая референц-поверхность (эллипсоид с другими параметрами или сфера), то и значения широт и долгот будут другими.Отдельно про разницу Меркатора и Веб-Меркатора (в интернете об этом много, но каждый новый раз не лишний)
Проекция Меркатора - это уравнения перехода от географических координат к плоским прямоугольным. Есть уравнения проекции Меркатора для сферы, есть для эллипсоида. Проекция Меркатора для эллипсоида WGS-84 это EPSG:3395 (WGS 84 / World Mercator) и только она. Судя по всему, её и использует Яндекс.
Проекция Меркатора для сферы это, например, ESRI:53004, но в каталоге есть и другие - для разных параметров сферы. Чтобы честно получить проекцию для сферы надо сначала перевести геодезические координаты в геоцентрические. Разница в том, что геодезическая широта - это угол между нормалью к поверхности и плоскостью экватора. А геоцентрическая широта - это угол между радиус-вектором и плоскостью экватора. На сфере нормаль и радус-вектор совпадают, а на эллипсоиде не совпадают. Поэтому чтобы корректно построить проекцию Меркатора для сферы, если у вас есть данные в датуме WGS-84, надо их сначала перевести в геоцентрические, и только потом выполнять проецирование на плоскость.
В веб-меркаторе (EPSG:3857) происходит следующий трюк: координаты используются геодезические на эллипсоиде, а формулы используются для геоцентрических координат на сфере. Из-за этого раньше возникала всяческая путаница и неразбериха, когда люди пытались одновременно использовать EPSG:3395 и веб-меркатор. Если пытаться просто совместить две карты в этих проекциях без дополнительных преобразований, то ничего не получится, всё разъедется.
Поэтому мой ответ на ваш вопрос "Для каких задач мне критично знать, что эти числа получены из Web Mercator?": для любых. Если вы знаете, что у вас данные в проекции веб-меркатора, вы просто указываете в метаданных код проекции 3857 и ГИС-ПО делает все нужные преобразования за вас. Если вы не знаете - у вас разные данные "разъедутся", и довольно сильно.
Не согласен с тем, что веб-меркатор какой-то неточный. Картографическая проекция не может быть точной или не точной. Картографическая проекция это взаимно-однозначное соответствие между географическими координатами и плоскими. Это условие для веб-меркатора сохраняется.
Неточными могут быть измерения, выполненные в этой проекции. Поэтому не надо делать в ней измерений - никакая проекция Меркатора для этого не предназначена, там очень большие искажения длин и площадей.
Неточным может быть преобразование координат - там используются разложения в ряды, там есть ограничения по точности со стороны арифметики с плавающей точкой. Но эти тонкости касаются уже геодезистов и тех, кто с кадастром рабоатет. Если вам надо плюс-минус метр, встроенные в ГИС-ПО преобразования Гельмерта "по умолчанию" вам подойдут.
Не ломается, но просто тормозит (i7-7700HQ, 20гб RAM, файлик на ~65 страниц с большим числом стилей, иллюстраций, внутренними ссылками, ссылками в Zotero)
А чем обеспечивается эта гарантия? Сама СУБД запрещает использовать одну временную таблицу двумя подключениями?
Мне казалось, я что-то такое делал
Большинство ресурсных спутников (те, которые поставляют высокодетальные снимки на большие покрытия относятся к этой категории) летает по солнечно-синхронной орбите. Она устроена таким образом, что местное время в подспутниковой точке всё время одинаковое (ну, почти одинаковое). Чтобы этого достичь нужна высота ~900км и отрицательное наклонение орбиты
Приведённая модель это довольно сильное упрощение того, что на самом деле происходит. В действительности положение внутритропической зоны конвергенции (это то, что между двумя "экваториальными" ячейками на вашей схеме) имеет ярко выраженную сезонную динамику, особенно на африканском континенте. Собственно, в эту сезонную динамику существенный вклад вносят и характер подстилающей поверхности (растительность/пустыня), и морские течения. Если бы Сахара не была пустыней, то сезонная динамика ВЗК была бы иной (и в Сахаре выпадало бы больше осадков).
Поэтому утверждение, что Сахара является пустыней вследствие глобальной циркуляции атмосферы верно лишь отчасти. Вторая часть заключается в том, что в процессе опустынивания был запущен процесс с положительной обратной связью, который привёл к текущему положению системы. А текущее положение является относительно стабильным, в нём глобальная циркуляция и региональные особенности "поддерживают" друг друга.