HTTP-сервер-обменник для тайлового кеша

[zOn]

Люди!
Бросте это гиблое дело - у вас нет тех ресурсов, которые есть у гугля и др.
Вы не сможете создать зеркало хоть одного из сервисов. Тот кто этим займется (т.е. будет все систематизировать) рискует попрощаться со своим винтом (мы это уже проходили, когда SAS еще небыло).

Обмен кэшем имеет смысл только для "уникального" контента, т.е. который вы сделали сами из любого картографического материала (исторические карты, ГШ, отрендеренный вектор и д.р.)
А смысла качать у товарища и мучать его и себя? Если тоже самое можно скачать у Гугля и д.р.

[Parasite]

Предлагаю ориентироваться по датам создания тайлов.

Минусы:

Минусы очевидны, но альтернатив-то нет, а сохраняя все различающиеся тайлы с их датами мы, по крайней мере не теряем данных.

Заблуждение номер раз: данные, содержащие неточности (в виде некорректных тайлов) - уже не данные, а зоопарк (и зоопарк в общем и целом, а не только в ошибочных тайлах, ибо отделять зерна от плевел глазками и ручками будет уже крайне сложно, а ложка дегтя, как известно - портит). Хранить его нет никакой нужды - уж лучше никаких данных вообще (и это утверждение будет исключительно TRUE), чем заведомо неверные в какой-то своей ненулевой части. Поправьте меня если я неправ.
Лично я полностью сношу и перекачиваю весь слой, если возникают хоть малейшие подозрения на зоопарк. Чего и Вам желаю.

Проблема с локальными временными зонами отчасти решается обещаниями пользователей

Это даже не смешно, не говоря уж о том что не сработает на деле.

Главное -- иметь все версии тайлов и не допускать, чтобы внезапно появившиеся новые снимки безвозвратно затирали фрагменты старых снимков создавая зоопарк.

Главное - иметь выкачанный без зоопарка полный слой. Толку от кучки тайлов версии N-1, если весь остальной слой - версии N, а версия N-1 уже недоступна из первоисточника и канула в Лету, и пожизненно собирать ее из присланного пользователями как-то лично мне кажется практически невыполнимым? Зачем хранить откровенный мусор, простите? Я понимаю если выкачан ВЕСЬ СЛОЙ какой-то версии полностью (без зоопарка в себе любимом) - он может и понадобится кому-то, а так......

Если опираться именно на даты создания - можно написать прожку, которая будет просматривать дату создания каждого тайла и сравнивать ее с 8ю соседями этого тайла со всех сторон.

Не совсем так. Надо просто формировать отдельный слой с градиентом, соответствующим дифференцированной матрице дат. Тогда более сильно отстоящие друг от друга участки будут подсвечиваться более контрастно.

Ок, допустим они подсветились. Что дальше?
Ситуация: я смотрю определенные зоны на 18м уровне, в разные дни (но в пределах одной гуглеверсии). Месяц, допустим, смотрю каждый день (и оно по кусочкам кладется в кэш), или три. Потом в конце концов плюнул и решил выкачать весь уровень. Выкачал, допустим, успешно.
При запаковке оного я получаю миллион подсветок, хотя уровень валиден (гуглеверсия на первоисточнике не менялась).

То же самое и в противоположном виде: поставил на ночь скачку, а в это время гугль поменял версию (а у меня продолжает качать). При запаковке получившегося зоопарка я получаю нуль подсветок при абсолютно неюзабельном многомегабайтном зоопарке. Последний пример - смена гуглеснимков (а я в это время как раз качал). Зоопарк пошел в корзину чуть более чем полностью, а качалка была озадачена скачкой по новой (причем ВСЕХ зумов начиная с нулевого).

Посему идея о какой-либо сверке с первоисточником (в идеале - проверка тайлов по CRC) таки открыта и вынесена на обсуждение.

Опять же, если более полной и качественной оказывается более старая версия тайлового слоя, то терять её ни в коем случае нельзя.

Слоя - да. Отдельного тайла - нет.
Про исключение же зоопарка именно на слое и идет речь, посему вопрос должен идти о версии слоя, а не версии тайла. И этот вопрос остается открытым: более радикальных идей чем проверка и аппрув глазками и ручками, и отказ в упаковке если не пройдены все аппрувы - у меня не имеется.

Поэтому хранение всех версий тайлов с датами -- пока единственный вариант

А Вы себе объемы представили? А процент трэша и зоопарка в этом обьеме, когда буквально доли процента зоопарка на слое может его испортить (а слой может весить и пару гигабайт и больше). Предлагаете это тоже хранить?
Посему, надо не хранить все вподряд что прислали Васи Пупкины - а уменьшать и предотвращать процент брака в имеющемся. Желательно превентивно, а не по факту его обнаружения у себя (то есть - ДО загрузки Васей Пупкиным в обменник).

без детальной проработки механизма контроля версий речи об нормальном двунаправленном обмене кэшем не идет.

Именно. Пока что можно лишь делиться кешем и брать его у других на свой страх и риск. Никого никогда не удастся делать работу за себя. Каждый должен проверять нужный ему участок сам. Ещё раз: проверяет не тот, кто делится, а тот, с кем делятся, то есть тот, кому это нужно. Не иначе.

Ага. Спасение утопающих - дело рук самих утопающих...?
Пример: я скачал слой на полтора гига в архиве. В нем - миллион тайлов, неизвестно как неизвестно какими путями и неизвестно когда и во сколько заходов выкачанных. Как мне предлагается его проверить, особенно принимая в виду то, что у меня этот слой и так частично есть в кэше? И если оно мне не подойдет (например там зоопарк до безобразия) - желаете ли Вы сказать, что я зря качал полтора гига с источника, указанного как "обменник кэша" (а не просто хранилище тайлового мусора для всех желающих)?

А свести СВОИ потери к минимуму при СВОЕЙ ошибке при импорте чужого кеша позволит возможность хранения всех версий тайлов с датами. А всякие там мечты и рассуждения о грандиозных валидаторах, утаптывателях, системах верификации, отката, аппрува и иже с ними останутся таковыми, ибо это АДСКИЙ труд. Надо реально смотреть на вещи.

"Адский труд" занимает пару страниц скрипт-кодинга по факту (где проверка на даты по соседям - пара строк, запрос аппрува ДА\НЕТ - еще пара, а все остальное - программирование TK-интерфейса и работа с графикой). Если Вы не желаете участвовать - не участвуйте. Никто же не заставляет именно Вас прямо сейчас бросить всё и делать этот "адский труд", право ж слово...

Нужна поддержка мультихранилищ. То есть когда тайлы одного слоя лежат не в одном хранилище, а в неограниченном кол-ве отдельных хранилищ.

Зачем?

Таким образом каждую отдельную проверенную детальную область, каждый отдельный импортированный участок и каждое нагромождение будет лежать в отдельном кеше и иметь отдельный индекс.

Выше Вы говорили, что проверять предлагается скачавшему, а не выкладывающему. Кто и как будет проверять "каждую отдельную проверенную детальную область", которая "будет лежать в отдельном кеше"? Предлагаете уповать на "обещания пользователей"?

При этом показываться всё должно в одном слое с возможностью гибкой фильтрации.

Вы предлагаете хранить и показывать тайлы?
Еще раз: выше была озвучена идея "банального" обмена кэшем - запаковка заведомо верных и проверенных слоев в архив, и выкладывание архива на ФТП с минимальным описанием (возможно, вынесенным в имя файла) для скачки всеми желающими. Мы все еще за эту идею, или уже опять за монстрообразный и избыточный "HTTP-обменник"? Если второе - то все вышесказанное прошу игнорировать, я обсуждал именно первое.

[Parasite]

Бросте
у вас нет
Вы не сможете
рискует попрощаться со своим винтом

Какое Вам, извините, дело до чужих винтов и чужих ресурсов? По существу темы имеете что сказать?
Если нет - не нагнетайте негатива. Надо искать пути решения проблемы, а не причины ею не заниматься.
Спасибо за внимание.

[zOn]

Какое Вам, извините, дело до чужих винтов и чужих ресурсов? По существу темы имеете что сказать?
Если нет - не нагнетайте негатива. Надо искать пути решения проблемы, а не причины ею не заниматься.
Спасибо за внимание.

Как говрится: дурак учится на своих ошибках.
Я хотел высвободить вашу энергию из бестолкового занятия на более полезное дело (например избавления от тайлового кэша и разработку нормальной индексации).
Ну раз вас чужой опыт не устраивает и вам хочется лично получить граблями по лбу, то несмею вам мешать

[Parasite]

Я хотел высвободить вашу энергию из бестолкового занятия

Спасибо за заботу. Воспользуюсь ©

избавления от тайлового кэша и разработку нормальной индексации

Лично мне неинтересна "нормальная индексация" - на ReiserFS всё прекрасно индексируется штатными средствами системы, а фрагментация стремится к нулю.

Ну раз вас чужой опыт не устраивает и вам хочется лично получить граблями по лбу, то несмею вам мешать

В чем заключается конкретно Ваш столь исключительный опыт, которым Вам не терпится поделиться? Вы б изложили, а народ бы почитал да обсудил Ваши грабли. А то как-то однобоко Ваш первый пост выглядит, извините.

[svp]

Ну раз вас чужой опыт не устраивает и вам хочется лично получить граблями по лбу, то несмею вам мешать

То, что кто-то получил по лбу граблями, незначит, что к граблям лучше не подходить вовсе=). Надо просто смотреть под ноги. А если грабли на приусадебном участке отрежут путь к сортиру? Извините за Эзопов язык=).

К делу. Насчёт борьбы с зоопарками.
Ув. Parasite, твои приоритеты не тоже самое, что приоритеты всеобщие. Мне, например, и многим, кто пользует Планету для ориентирования, неприемлема перекачка огромных территорий только потому, что возник незначительный зоопарк. Не через один же тайл у нас получилась шахматная доска из версий тайлов... К тому же многим будет интересна возможность видеть именно разные версии тайлов. То есть переключаться между версионными слоями (назовём их Срезами), как это позволяет делать, например, новая (пятая) версия GoogleEarth.
Надеюсь никто не будет спорить со следующими предпосылками в вопросах обмена и хранения кеша:

1. Не желательно терять большие объёмы закачанного кеша.
2. Желательно иметь возможность переключаться между версиями снимков.
3. Желательно иметь возможность откатить последнюю операцию (или несколько последних операций) добавления участка в основной кеш.
4. Желательно иметь возможность просматривать импортируемый (или недавно закчанный потайлово) участок кеша отдельно от остального кеша на предмет аппрува.
5. Желательно иметь возможность видеть границы недавно закачанного (или импортированного) участка кеша на предмет определения соответствует ли этот участок тому, что уже имеется в основном кеше.

Ремарка: Речь идёт о более-менее комплексном подходе к решению нашего букета проблем. При этом постараемся не забывать о преемственности старых версий и об относительной простоте реализации новых идей.
Исходя из этого имеет, полагаю, смысл:

1. Ввести понятие: Срез -- это обособленный по тем или иным причинам участок кеша.
   • В пределах слоя или карты может создано сколько угодно срезов.
   • Срезы могут пересекаться между собой по координатам.
   • Технически срез должен храниться изолированно и не заменять своими тайлами тайлы других срезов.
   • Срезы можно "мысленно" сортировать в любом порядке, просматривать отдельно и вместе с некоторыми (или всеми) другими срезами.
   • Срезы можно объединять в один.
   • Легко определять пересекаются ли срезы, и если да, то где конкретно.
   • В свойствах среза можно указывать интервал дат закачки, источник, комментарий и т.д.
   • Срез может включать в себя несколько масштабов.
   • Правильный срез, он же "Подписанный" срез -- это срез, тщательно проверенный модератором и заверенный его цифровой подписью (позже можно реализовать, и ничего в этом сложного нет). Должен содержать цельный участок детализации без зоопарка. В случае неполноты закачки участка должна присутствовать соответствующая пометка.
2. Ввести понятие: Хранилище -- совокупность программных средств, обеспечивающая хранение набора срезов.
   
   • Каждая карта и каждый слой соответствуют отдельному хранилищу.
   • Сейчас разрабатывается единый интерфейс хранилищ. Он позволит единообразно обращаться к любым хранилищам тайлов. Для этого надо будет лишь реализовать адаптер -- класс, который будет реализовывать интерфейс хранилища.
   • Единый Интерфейс может быть реализован на любом типе хранилища (от БД до файловой структуры, как сейчас).
3. Пользователь может добавлять в свои хранилища любые срезы
4. Срезы можно сортировать, а также включать и выключать их видимость.
5. Срезы можно проверять на пересечение и объединять. Опционально можно проверять их различными алгоритмами, например перекрёстным сравнением дат, как предложил Parasite.
6. Срезы можно сколь угодно долго использовать не слитыми воедино. Интерфейс хранилища устроен так, что будет брать тайлы из срезов в соответствии с их приоритетами и видимостью.
7. Каждый новый текущий сеанс закачки начинается в новый срез. При завершении сеанса опционально можно предлагать пользователю визуально проверить соответствие только что закачанного одному из срезов, существовавших ранее.
8. Каждый, кто захочет участвовать в обмене, должен оставить в обменнике открытый ключ для того чтобы все могли проверить его подпись под срезом. Авторов косых срезов мы не будем уважать=).
9. Некоторые срезы объединять в принципе не разрешается. Это либо разные версии снимков, либо разные изолированные детальные территории. При этом мы получим минимальную вероятность зоопарков, максимальную понятность и прозрачность операций, максимальную надёжность, минимальную избыточность.
10. В перспективе у нас появляется возможность реализации кросс-сервисного хранилища. То есть будет возможность на одной карте видеть срезы с разных сервисов. К примеру, есть сервисы, предоставляющие одни и те же снимки но в разном объёме, а хотелось бы видеть максимальное покрытие интересующей территории детальными снимками.

Я прошу прощения, за такое количество слов, надеюсь никого не атруднил их прочтением и меня не забанят за флуд и оффтоп.=)
Обсуждения технической стороны вопроса, думаю, следует продолжить в другой теме. Здесь давайте рассматривать концептуальные вопросы такого вот верифицирования тайловых данных.

[Parasite]

[отселя немного тематического оффтопа]

Ув. Parasite, твои приоритеты не тоже самое, что приоритеты всеобщие.

Ув. svp, то же самое имею сказать и тебе (причем далеко не в первый раз, и причем я далеко не первый). Давай не будем говорить за всех - но почему-то только с твоей отдельно взятой стороны, а подходить к проблеме по мере ее появления (и как можно более чаще оперировать понятием "имхо").
На настоящий момент проблема звучит как "Народ хочет (см.сабж) обменник валидным (валидным, повторяю)) текущим (для начала) кэшем для всех (всех, повторяю) желающих энтузиастов. Сейчас, по возможности. Не через год и не через пять (пока кто-то там разродится с индексацией в свободное от работы время, еще кто-то - с многосотенногигабайтным хостингом, а третий - со свободным временем и знаниями для реализации всего этого), и если к тому времени народу еще не расхочется".

Мне, например, и многим, кто пользует Планету для ориентирования, неприемлема перекачка огромных территорий только потому, что возник незначительный зоопарк.

А мне, например, и и многим, кто пользует Планету для склейки карт и дальнейшей (опциональной) печати оных, обязательна перекачка огромных территорий только потому, что возник совершенно незначительный зоопарк. Или же я например просто хочу, чтобы у меня всё было КРАСИВО на экране, а не как в аттаче (и банальный заход браузером на гугль мне это дает - в отличие от предлагаемого тобой варианта). Мне нельзя этого хотеть? Хочешь ли ты сказать, что хотелки первого типа (описанного тобой) много важнее хотелок второго (описанного мной) только потому, что именно тебе хочется именно первого? Три раза ха-ха, пардонэ муа.

Попрошу также отметить, что юзеры первого типа (например ты) вовсе не откажутся от нормального кэша на фоне имеющегося по факту зоопаркового, а юзерам второго типа (например мне) зоопарк и так лучше не предлагать. Приоритеты и векторы желаемого направления решения вопроса устраивающего ОБЕ группы расставишь сам.
[доселя немного тематического оффтопа]
Продолжаем по теме.

Не через один же тайл у нас получилась шахматная доска из версий тайлов...

Аттач после смены гуглеверсии в процессе скачки. Смотри сам...Комментарии излишни.
Если ты готов пользоваться ЭТИМ гуано "для навигации" - твое право. Могу отдать даром - зайди как-нибудь с винтом....а для себя я все ж перекачаю, хоть это и займет время. Искусство требует жертв.

К тому же многим будет интересна возможность видеть именно разные версии тайлов. То есть переключаться между версионными слоями, как это позволяет делать, например, новая (пятая) версия GoogleEarth.

1. Интересна возможность переключения не ТАЙЛОВ, а именно слоев из этих тайлов. ПОЛНЫХ слоев, без зоопарка и дырок на каждом. Это, безусловно, интересно.
2. На ГЕ именно полные слои, и сервис ГЕ прекрасно знает - какой тайл какому слою принадлежит. Соответственно, им нет никаких преград переключать слои сколь угодно часто и в каких угодно рамках. У нас же полных слоев вряд ли соберется даже в теории, если специально не заняться именно этим вопросом сохранения полных версий, и заняться прямо сейчас.
Ключевые слова в обоих пунктах - версии полных слоев. Применения же разным версиям отдельных тайлов (не составляющих полного слоя в своей массе) лично я не вижу.

Не желательно терять большие объёмы закачанного кеша.

...если он представляет из себя как минимум полный слой (сколь угодно старой версии, но полный слой).
Кого-то из присутствующих интересует регион пгт.Усть-Зажопинска Рязанской области, выкачанный в феврале позапрошлого года, неполностью, с неопределенными границами, в разные даты и по разным зумам? Если такие есть - пожалуйста, отпишитесь ниже (коль скоро тут голосований нет...)

Я прошу прощения, за такое количество слов, надеюсь никого не атруднил их прочтением и меня не забанят за флуд и оффтоп.=)
Обсуждения технической стороны вопроса, думаю, следует продолжить в другой теме. Здесь давайте рассматривать концептуальные вопросы такого вот верифицирования тайловых данных.

...а так как до всего вышеописанного еще КРАЙНЕ далеко (и я крайне сомневаюсь, что это вообще когда-нибудь увидит свет) - то пока суть да дело, следует проработать более банальные пути обмена кэшем (например, архив с описанием+ФТП). Что я и предлагал выше. Давайте решать проблемы по мере их появления - и проблема на настоящий момент в том, что на фоне закручивания гаек с баном у гугла качать ОХОТА, но качать много НЕ ПОЛУЧАЕТСЯ. Вот прямо сейчас охота и прямо сейчас не получается. Отсюда два выхода: либо начать хоть как-то но меняться уже сейчас, либо ждать до морковкиного заговенья всего описанного камрадом svp (а к тому времени либо ишак сдохнет, либо падишах помрет, либо Гугль обанкротится, либо пользователи САСа не один раз сменятся поколениями...).

Мысли в студию.

[svp]

Не затронул один важный аспект насчёт того, куда будут попадать тайлы, загруженные в ходе текущего просмотра. Пользователь, же, может за один сеанс работы посмотреть кучу городов и мест, а каждый из этих изолированных регионов детализации может быть обновлён веб-сервисами отдельно.

Направлений решения его я вижу несколько:

1. В ручную или автоматически (методом обхода по правилу левой руки) строятся границы всех попадающихся изолированных детальных областей. Все тайлы, загруженные в ходе просмотра в пределах одной изолированной области попадают в один срез.
2. Срезы в хранилище размещаются в виде списка, но визуально их можно отображать в виде дерева с отключаемыми элементами и мультивыделением.
3. Я и vdemidov сейчас заканчиваем реализацию древовидного индексатора тайлового кеша. Реализуем один принцип двумя подходами. Посмотрим что получится эффективнее и быстрее. Индекс позволит производить быстрые операции проверки принадлежности тайла кешу (хранилищу, срезу), объединения, вычитания, пересечения индексов разных хранилищ и срезов. Индексы будут снабжены итераторами для обхода тайлов фрагмента разными способами. Индекс также позволит ОЧЕНЬ быстро отрисовывать область заполнения до любой глубины. Эта скорость, как и размер индекса, не будет зависеть от количества тайлов. Операция определения пересечения двух срезов также будет происходить очень быстро.
4. Срезы можно подразделять на три типа: автоматически созданные (или сеансовые), претенденты на подпись и проверенные с подписью. Это позволит не загромождать список срезов.

Теперь задача состоит в том, как МАКСИМАЛЬНО просто всё это реализовать, как сделать простые программные интерфейсы доступа к выше описанным функциям, и как не слишком заморачиваясь соблюсти компромисс между реализуемостью и стремлением к идеалам.
Иема очень непростая, поэтому прошу взвешивать свои слова, максимально продумывать доводы и не бросаться фразами "всё это хрень и не будет работать" или "это нереально сделать, ибо мне кажется это нереально сделать". Пока что я не вижу объективных причин, почему бы такой механизм не прокатил. Если вы видите объективные причины, то прошу участвовать в обсуждении.

[svp]

А вот с тривиальным обменом что-то у вас, ребята, дело стало... С архивами и прочим.

[!]MODERATED:OFFTOPIC

[Parasite]

А вот с тривиальным обменом что-то у вас, ребята, дело стало... С архивами и прочим.

Кому интересен обмен кэшем архивами через ФТП - пожалте в личку за адресом и прочим. Место - есть, траффик - есть, какой-то кэш (мой личный, беззоопарковый) - есть, готов поделиться и посмотреть на предложенный с вашей стороны.