Комментарии 68
Интересно, что у этой статьи на Хабре за день наверняка будет больше просмотров, чем посетителей у Спутника за тот же период времени.
Еще бы кто-нбудь объяснил вообще этот дикий велосипед под названием «Спутник» нужен…
Возможно потому, что скоро самым страшным оружием будет не ядерное, а информационное.
Зачем, зачем. Вот начинается война, США перерубает интернет и дает команду на перманентное отключение всем Windows, а мы активируем нашу чебурашку вместо глобального интернета, включаем яндекс вместо гугла, спутник вместо гуглмэпс. Никто не заметит подмены.
Но… у Яндекса ведь тоже есть карты…
Во минусуют-то) А ведь до США может и долететь что нибудь, что не станет ни гугла, ни майкрософта. Резервные российские подобия разных заморских сервисов должны быть обязательно.
То есть вместо того чтобы вести себя подобающе — мы на жопу лист металла нашьем чтобы ремнем не больно было? Хорошая тактика.
Больше карт хороших и разных!
«Спутник» еще существует? О_о
Почему нет?
Обычный пользователь про него не забывает.
Обычный пользователь про него не забывает.
А как на этого пользователя посмотреть? Просто интересно, какая аудитория им пользуется и где. У меня, как и у многих на хабре, наверное, нет знакомых, кто пользуется «спутником». По крайней мере я пока таких не встречал, зато встречал пару людей, которые пользуются стикерами в viber — вот это находка, но это оффтоп.
У меня вопрос о праве использования.
В настоящее время Соглашение об использовании гласит:
Понятно, что продавать ваши тайлы, а получать за это свои деньги по такому Соглашению никак нельзя: это было бы явно коммерческое использование.
А какие ещё формы использования можно считать коммерческими и поэтому не разрешёнными?
Не очень понятно.
Возможно, было бы полезно вам объяснить это обстоятельство на одном или нескольких примерах такого рода:
Какие из этих действий разрешены вашим Соглашением, а какие нет?
В настоящее время Соглашение об использовании гласит:
Материалы, входящие в состав контента, предназначены исключительно для некоммерческого использования.
Понятно, что продавать ваши тайлы, а получать за это свои деньги по такому Соглашению никак нельзя: это было бы явно коммерческое использование.
А какие ещё формы использования можно считать коммерческими и поэтому не разрешёнными?
Не очень понятно.
Возможно, было бы полезно вам объяснить это обстоятельство на одном или нескольких примерах такого рода:
- Размещение карты на сайте такого магазина, который от наличия карты получит дополнительный приток покупателей (узнавших как добраться) и коммерческую прибыль.
- Размещение карты на сайте такой справочной службы, на сайт которой адреса попадают за плату, так что и установка карты производится как бы в счёт этой платы и именно как платная услуга (хотя вряд ли за отдельную плату).
- Размещение карты на сайте, на котором висит реклама и приносит прибыль владельцу за счёт демонстрации карты вместе с рекламою всем, кто интересуется маршрутом.
Какие из этих действий разрешены вашим Соглашением, а какие нет?
Чтение вон той статьи в NiemanLab убеждает меня, что термин «некоммерческое использование» считается вовсе не ясным и на Западе, а не только у нас в России.
И поэтому он нуждается в непременном подробном разъяснении, а меж тем у «Спутника» в его Соглашении об использовании никакого разъяснения нет.
И поэтому он нуждается в непременном подробном разъяснении, а меж тем у «Спутника» в его Соглашении об использовании никакого разъяснения нет.
Дежавю. Был ведь уже этот пост: sohabr.net/habr/post/252359/
Пишите! Очень интересно как мыслит и что делает команда Спутника.
Вроде как ребята там на самом деле нормальные
Интересно какую файловую систему выбрала команда Спутника для тайлового хранилища. У меня Empty Tile занимает 103 байта. На блочной файловой системе с большим блоком это расточительно…
Подскажите, а какую файловую систему вы выбрали для хранения тайлов?
Подскажите, а какую файловую систему вы выбрали для хранения тайлов?
Couchbase © forum.openstreetmap.org/viewtopic.php?id=29982
А были ли эксперименты с RamFS/TmpFS? Овчинка выделки стоит?
Как ты себе представляешь ramfs на несколько терабайт? Ок, возможно, если распределить тайлы по нескольким серверам, использую при этом хэш алгоритм. Но если сервер ребутается? Ждать n-ое количество времени пока тайлы из постоянного хранилища запишутся в ramfs?
На случай ребута лучше иметь парочку таких серверов и настроенный балансировщик, которому на время ребута одного из серверов необходимо указать использовать только оставшуюся рабочую машину.
По поводу терабайт. Я рассматриваю вариант размещения в RamFS тайлов до 17-го масштаба (по моим подсчетам около 1,3ТБ). Да, это много, но нынче оперативка относительно дешевая (главное, чтобы проект этого стоил :) ).
Есть еще несколько мыслей по поводу оптимизации размера tile storage. Если размещать данные, например, в Redis'е (т.е. тоже в оперативке), а не в файловой системе (даже в TmpFS), то удается сэкономить около 30% емкости за счет отсутствия необходимости хранить каталоги (которые в файловой системе, как известно, тоже занимают определенный размер), отсутствия проблем с незаполнением блоков, т.е. за счет более эффективного использования ресурса (оперативки по сравнению с файловой системой). Кстати, Redis умеет реплицироваться, что существенно упрощает решение проблемы разворачивания/ребута еще одного сервера, участвующего в балансировке.
Еще я заметил, что до 70% тайлов дублируются (проверял по контрольной сумме SHA1). Как правило, это океаны, пустыни и пр. Т.е. так называемые Empty Tiles по 103 байта. Даже на этом можно попытаться сэкономить место. Например, symlink в среднем занимает 20 байт, т.е. до 70% тайлов можно в пять раз компактнее хранить, что примерно составляет около 50% емкости tile storage. Другое дело, что вычислять контрольную сумму — дело дорогостоящее для миллиардов тайлов. Пока это только мои исследования. Возможно, позже напишу статью на Хабре о результатах.
P.S. Все время не покидает ощущение, что я хожу хоженными тропками, горожу велосипед и т.п., но, к сожалению, мудрость черпать неоткуда, кроме как из ваших скудных (да простите меня за откровенность) ответов.
По поводу терабайт. Я рассматриваю вариант размещения в RamFS тайлов до 17-го масштаба (по моим подсчетам около 1,3ТБ). Да, это много, но нынче оперативка относительно дешевая (главное, чтобы проект этого стоил :) ).
Есть еще несколько мыслей по поводу оптимизации размера tile storage. Если размещать данные, например, в Redis'е (т.е. тоже в оперативке), а не в файловой системе (даже в TmpFS), то удается сэкономить около 30% емкости за счет отсутствия необходимости хранить каталоги (которые в файловой системе, как известно, тоже занимают определенный размер), отсутствия проблем с незаполнением блоков, т.е. за счет более эффективного использования ресурса (оперативки по сравнению с файловой системой). Кстати, Redis умеет реплицироваться, что существенно упрощает решение проблемы разворачивания/ребута еще одного сервера, участвующего в балансировке.
Еще я заметил, что до 70% тайлов дублируются (проверял по контрольной сумме SHA1). Как правило, это океаны, пустыни и пр. Т.е. так называемые Empty Tiles по 103 байта. Даже на этом можно попытаться сэкономить место. Например, symlink в среднем занимает 20 байт, т.е. до 70% тайлов можно в пять раз компактнее хранить, что примерно составляет около 50% емкости tile storage. Другое дело, что вычислять контрольную сумму — дело дорогостоящее для миллиардов тайлов. Пока это только мои исследования. Возможно, позже напишу статью на Хабре о результатах.
P.S. Все время не покидает ощущение, что я хожу хоженными тропками, горожу велосипед и т.п., но, к сожалению, мудрость черпать неоткуда, кроме как из ваших скудных (да простите меня за откровенность) ответов.
В Couchbase тоже есть репликация, которая появилась задолго до появления оной в Redis. И тоже есть возможность хранить данные только в памяти. На тему метаданных. В Couchbase метаданные на каждое значение составляют 56 байт. Чтобы использовать метаданные с пользой, лучше в каждый ключ записывать информацию о 8x8=64 тайлах (метатайл).
Издёвки издёвками, а работает этот сервис реально быстро! Я зашел, потыкался, и был очень приятно удивлён.
Ощутимо более отзывчив, чем гугл и яндекс
Ощутимо более отзывчив, чем гугл и яндекс
Не мудрено, отзывчивость обратна пропорциональна количеству пользователей.
Советую попробовать openstreetmap.ru/, тоже довольно быстро.
Там справа внизу ссылка «Обратная связь»
2) Похоже на «место для автостопщиков» и «лавочку»
Так возьми и исправь карты сам на osm.org, в чём проблема то? Это ведь открытые карты.
1)Сколько времени занимает обновление контента с момента правки в OSM? Последний раз прождали более 4 месяцев
2)Хотим использовать карты на проекте, у нас API Openlayers. Добавление спутника в источники приводит к ошибке
Возможно ли добавление Access-Control-Allow-Origin:* в ответ вашего сервера?
2)Хотим использовать карты на проекте, у нас API Openlayers. Добавление спутника в источники приводит к ошибке
Image from origin 'http://c.tiles.maps.sputnik.ru' has been blocked from loading by Cross-Origin Resource Sharing policy: No 'Access-Control-Allow-Origin' header is present on the requested resource., приходится использовать проксирование — скачивать для каждого клиента карту и передавать ему.
Возможно ли добавление Access-Control-Allow-Origin:* в ответ вашего сервера?
Ого, уже первый pull request: github.com/sputnik-maps/gopnik/pull/1
Расскажите лучше о поисковом движке. Он же на ерланге, да?
Если вы про геопоиск, то он тоже на Go.
Нет, про обычный. Я вот эту вакансию на hh.ru видел и приметил что в юзаете erlang
А на сервисе спутника только векторные карты? Спутниковых снимков не предусмотрено?
А каким импортером osm вы пользуетесь?
У нас импорт RU.osm.pbf на osm2pgsql занимает 691 минуты, а на imposm3 11 минут.
Если вы пользуетесь imposm3, то меняли ли вы маппинг в imposm3 или в mapnik?
У нас импорт RU.osm.pbf на osm2pgsql занимает 691 минуты, а на imposm3 11 минут.
Если вы пользуетесь imposm3, то меняли ли вы маппинг в imposm3 или в mapnik?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как это работает: архитектура тайлового бэкенда карт «Спутника»