Pull to refresh
84
0
Дорофей Пролесковский @Komzpa

User

Send message
Так почему просто не посчитать целевую функцию для каждого гекса и так и оставить, раз она хороша? Зачем генерить делоне, чтобы потом на через шаг его выкинуть? Почему заречье выкидывается до того, как наложена целевая функция, ведь она может сказать, что туда возить выгодно?
Кажется, минимум половина шагов лишняя, а методы применялись рандомно и без осмысления?

Зачем так сложно, если в результате получилась просто растеризованная поверхность функции потерь?
Привет, Кирилл.

Во-первых, я программист на зарплате. Ну, или менеджер. Не суть. Я уделяю время софту.

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

У меня есть текущие проблемы. Одна из них — общая для многих — «нужна карта на фон». В зависимости от количества пользователей софта, в котором эта карта на фон нужна, сложность решения может быть от «вставить айфреймом osm.org/export/embed.html» для странички в личном блоге до «написать свой кластерный рендер-стек и систему ревью правок», если ты фейсбук.

Примерно с момента «десять промотал пять 4К-экранов с картой» osm.org раньше начинал тебя притормаживать, а многие отдалённо близкие к админам, кому ты начинаешь жаловаться на тормоза с картой — истерично посылать поднять свой тайл сервер, «потому что не должны раздавать карту всему миру».

Проблема в том, что это решение — стрельба из базуки по короновирусу. Как простой смертный, я едва выюзаю сотую мощности «своего тайл сервера». Если у меня есть ещё пользователи — окей, реалистично — до десяти процентов даже на очень большом проекте, дальше — зона почти фейсбуков и яндексов. Вся Беларусь пользователей OpenStreetMap не загружает 100-мегабитный канал одной машины десятилетней давности.

Экономически варианты «поднять свой тайл-сервер и пользоваться им в одиночку» и «пожертвовать сорок баксов в месяц на осм.орг» для меня на уровне неразличимости. В первом варианте получается тайл-сервер только для меня и 0.1% утилизации, во втором — потенциально тем же сервером пользуются ещё и все остальные. Мне не жалко.

Что происходит в OpenStreetMap? Есть популярная карта про Pokemon Go с официальными тайлами осм.орг в подложке. Владельца просят снизить нагрузку. Владелец предлагает не банить его и приносить $500 пожертвованиями в месяц, которого хватит на сервера на десять таких карт. Карту банят по рефереру, по владельцу топчутся и вытирают ноги, как он смел использовать бесплатные тайлы бесплатно.

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

Но это — исключение: легализованной схемы, которая бы позволила компании пойти подарить рендер-ноду в осм и оставить за собой право пользоваться её мощностями без дурных ограничений сейчас нет, и всем компаниям рекомендуется занести копеечку в мапбокс.
А можете рассказать, как человек «не в теме», что такое «подключить OSM», для «людей в теме»?
для того, как она используется в том месте планировщика, нужно считать не корреляцию, а оверлап между соседними страницами брина. здорово, что её придумали для одномерных типов считать через корреляцию, но не очень правильно так поступать для многомерных.
Нашёл статью, пока пытался разобраться с неиспользующимся BRIN-индексом в PostGIS.
В общем, инфраструктуре BRIN нужно, чтобы кто-то посчитал Correlation статистику, и чтобы она была значительно больше 0, иначе оно скажет «надо читать индекс целиком» на планировании. Кажется, это бага и в постгисе и в типе box.
trac.osgeo.org/postgis/ticket/4625#ticket
У эллипсоида нет нормальной обратной формулы перехода из меркатора в широту-долготу, те, что есть — численными методами считают суммы рядов, пока не покажется, что они сошлись. Можно потерять 0.6% точности и получить обратимую формулу. На вашем экране нарисуется три-четыре лишних строки пикселей, которые вы вряд ли заметите, а программисты не будут сходить с ума от взрывающейся накопленной ошибки при преобразованиях в и из меркатора.
Отличие «веб-Меркатора» заключается в в том, что за пределами широт в примерно ±85° используется другая проекция, которая не уходит в бесконечность в полюсах.

Web Mercator отличается от правильного World Mercator тем, что считает Землю сферой, а не эллипсоидом (отчего он же называется Spherical Mercator). Никаких волшебств с 85 градусом никто нигде не делает, 85.011 — это широта, на которой бесконечный цилиндр срубается в квадрат, все севернее и южнее в веб-картах просто выкидывают, там все равно никто не живет.

А кто хочет купить настоящие (не токенизированные, без гмо и блокчейна) акции Gett, напишите мне, договоримся в частном порядке.

make можно передать -j без числа, тогда он запустит параллельно всё, что может, а разбирается уж пусть планировщик ОС.
json-объектом — не является. Но JSON (в ECMA-404 в частности) не обязывает на верхнем уровне держать именно объект — там должен быть Value, а он уж может быть объектом, а может быть и числом.

www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf
Да, хорошей антенны не будет. Более того, не будет даже адекватно смонтированной плохой. Тут бы хотя бы брать что-то хакабельное, чтобы в ужасной физике можно было хоть что-то делать постфактум софтом :)

Особой веры в новые чипы нет — искал по всем даташитам, что стоит в моём же Note8, в итоге оказалось, что в чипсет 2017 года вварен приёмник дизайна 2013 года.
Наша высокоточка (5-7 мм СКО) работает на приемниках ценой 2000 рублей. Но, разумеется, расчеты делаем мы сами.


А что за приёмники? Есть ли они в составе каких-нибудь готовых китайских андроидных телефонов? :)
А есть практическая имплементация метода, или это теоретические изыскания?

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

Метод мог бы работать, если бы существовали API для того, чтобы заставить оба приёмника «цепляться» за одинаковый список спутников, или в совершенно чистом поле. Когда в некоторых частях города не видно почти всего неба, кроме пятачка прямо вверх — причём, как показал Uber, достаточно разного пяточка, чтобы можно было уже из этого делать выводы — считать ошибку коррелированной между приёмниками несколько самонадеянно.

image
Это, кстати, интересное замечание — API для получения SNR до конкретного спутника было уже в Android API level 3, и
в статье используется именно SNR. developer.android.com/reference/android/location/GpsSatellite

Есть ощущение, что GNSS API делалось в частности для того, чтобы не отдавать позицию, полученную по Beidou, чем-то системным с названием «GPS».
DOP уже достаточно давно неактуален как значение, android и ios склонили рынок к тому, что теперь сами чипы прямо в NMEA-потоке репортят accuracy именно в том виде, в котором ожидает OSRM — как минимум на подопытном MTK в составе ZTE мы это наблюдали.

Решали ли вы, и решили ли, проблему систематической погрешности в gps, когда приёмник репортит координаты с отличной относительной, но ужасной абсолютной погрешностью? У нас в данных довольно частая история — трек идеально повторяет контуры дороги, но в пятистах метрах от неё, за пределами всех радиусов для мап-матчинга.

А вы живёте на Free Tier в Mapbox, или у вас почти нет трафика? Для коммерческих клиентов они не стесняются делать кастомные решения.
Тут стоит упомянуть, что за API Mapbox стоит опенсорсный движок OSRM, в котором можно в конфигурации выключить ограничение в 100 точек, если не полениться развернуть его на своём сервере.

Кстати, год назад ваш подход бы совсем не работал — изменение, которое позволяет передавать в OSRM трек одиночный, в котором есть неравномерные провалы во времени (а у вас они есть, вы ведь используете двумерное упрощение Дугласа-Пойкера вместо фильтрации), закоммитил хабраюзер Gard github.com/Project-OSRM/osrm-backend/pull/3815

С погрешностью всё довольно просто — она внутри преобразуется в радиус поиска дороги-кандидата, больше значение gps_precision — медленнее обработка, но более разнообразные варианты могут быть восстановлены. В коде радиус просто множится на три, и если этого значения нет совсем, его можно прикинуть по карте — взять типичное расстояние между двумя параллельными дорогами в вашей местности и поделить его на три. Ребята из lyft нашли регрессией более оптимальную формулу для нахождения радиуса, по своим данным — github.com/Project-OSRM/osrm-backend/pull/3184 — но оказалось, что с такой формулой перестаёт работать мапматчинг у тех, кто не озаботился передачей настоящего значения accuracy и придумывает его сам, как у вас.

Так и живём.
Вообще, дорога вам лежит в postgresql-hackers, в тред www.postgresql-archive.org/Bitmap-scan-is-undercosted-td5995072.html — там как раз начали обсуждать, почему bitmap and считается более скоростным планом, чем скан по одному индексу.
По умолчанию Postgres считает, что в данных нет внутренних корреляций и селективность одной колонки можно просто перемножить на другую, чтобы получить общую селективность. Нативный путь чинить это — создать статистику на пару колонок, www.postgresql.org/docs/10/static/sql-createstatistics.html
А почему вы сразу пытаетесь начать с обмана планировщика, вместо того, чтобы сделать ANALYZE проблемной таблице и убедиться, что по ней вовремя ходит autovacuum?

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity