Parasite писал(а):Как будем отрабатывать некачественные\битые\просто левые тайлы? Например, закачка тайла прошла с ошибкой, размер и соответственно CRC будут отличаться. Либо скрипт у кого-то локально глюкнул и начал качать несколько не те тайлы, что нужно, и у нас начал появляться кусок океана посреди Садового Кольца (у меня так было как-то раз в какой-то из ранних версий САСа). Наши действия?
Битые и несоответствующие CRC файлы в кеш сохранять не следует ни при каких обстоятельствах.
Если косячит алгоритм закачки и неправильно именует тайл, то эта проблема к версии относится слабо. Если версий не учитывать вовсе, то старого варианта не останется и придётся перекачивать ошибочные участки. С версией (по приведённой выше схеме) достаточно удалить тайлы косой версии в локально накосяченом участке.
Опять же можно строить тайлы карты заполнения с учётом версий и быстро находить потенциально битые участки по номеру версии.
По логам следовало бы, конечно, вычислить ещё пользователя писавшего такие тайлы и попросить его не хулиганить. Чтобы лог не достиг эпических размеров определить понятие сессии и запись тайлов производить в пределах этой сессии. Логировать. соответственно, сессию вместе с баундами, в пределах которых аплоадились тайлы в этой сесссии.
Итак, добавляем в ТЗ:
-- Поддержка сессии записи в кеш. Хранить за сессией IP клиента (в идеале ещё ID зарегистрированного пользователя), ректангл координат загруженных тайлов, даты начала/конца сессии. Определить таймаут на автозакрытие сессии.
Parasite писал(а):На Гугле это видно визуально (сорри за тавтологию), и опять же если версия кэша меняется - то она меняется разово на всех относящихся к данной версии тайлах. Присваивать же номер версии каждому отличному от других тайлу - получится веселенький такой зоопарчик, особенно если выйти с локалхоста на просторы многопользовательского режима (в т.ч. и на запись в базу).
Именно так. Даже если тайлы на гугле не отличаются от старых, версия их уже новая. Хранить много копий одних и тех же данных нерационально. Версии же нужны. Например недавно (в пределах нескольких месяцев) обновились детальные снимки Парижа. Причём старые снимки были качественнее и с лучшей цветопередачей. Они лучше годились для печати. Были просто красивее.
По данным с гугла отличить старые это тайлы или новые, по ходу, никак нельзя.
При отсутствии параметра "v", повторюсь, выдавать тайлы максимальных версий. При указании конкретной версии следует выдавать тайлы с версиями НЕ БОЛЬШИМИ указанной. То есть, если нет тайла с указанной версией, то выдаём тайл с ближайшей меньшей версией.
Parasite писал(а):Например, та же Москау может быть (у нас) довольно "высоких" версий так как будет пользоваться "повышенным спросом" и соответственно будет иметь "повышенный шанс еррорности"
Ещё раз: битые и косые тайлы не помещаем в кеш. Если они туда как-то попали, их надо оттуда вычищать. При этом хранение разных версий тайлов нам наруку! Ещё раз напомню, наши версии тайлов ничего общего с версиями гугла и прочих сервисов не имеют.
Выходит в Москве прибавятся новые версии только в случае, если гугл действительно переснял территорию.
Parasite писал(а):а к примеру Усть-Зажопинск может быть вообще в "единичной" разово укачанной версии - несмотря на то, что по гуглю это будут тайлы ОДНОЙ гуглеверсии. Соответственно при выводе уже нашей карты "последней версии" - мы увидим Москау, но не увидим Зажопинска (а на гугле как раз будет всё ОК).
Я там выше дважды писал, что при запросе тайла i-ой версии сервер должен возвращать тайл с максимальной версией, но меньшей либо равной i. То есть Зажопинск будет виден наравне с Москвой. А если версия не указана. то по умолчанию считать её равной максимально возможному числу. Вот и всё.
Проблема может возникнуть только для сформированных слоёв. Однако в правилах сервера следует запретить закачку на него сформированных слоёв. Формировать слои должны админы.
При хранении тайла, помимо версии, надо хранить битовый флаг, указывающий на то, сформирован ли он, или закачан, сформированные тайлы от клиентов не принимать. Хотя эту политику, пожалуй, стоит обсудить. В крайнем можно делать приблизительное сравнение распакованных в битмапы тайлов на предмет определения различаются ли их исходники.
