svp писал(а):А есть вообще возможность определить текущую версию гугла?
Подсмотрев в родные ссылки гугла. Опять же там (скорее всего) меняется не весь движок MapAPI на яве, а скорее всего именно одна из ХМЛок с нач.установками вообще и с версией в частности. Но не уверен. Займусь, разберусь, дам знать.
svp писал(а):Не будет ли выходом хранение вместе с тайлом даты его закачки? У файла это дата создания.
Не будет. Одни и те же тайлы можно качать в разное время - как и разные тайлы в одинаковое (многопоточно). Да еще и разницу во времени между юзерами нужно будет принимать ввиду, и девиации и поправки на неточность установленного времени на стороне пользователя...Будет зоопарк, короче.
svp писал(а):Зная даты обновлений достоверна ли будет фильтрация тайлов по дате? То есть тайлы закачанные после даты выхода обновления можно ли считать гарантированно новыми?
Выходом будет премодерация новых тайлов на фоне старых, и визуальное совпадение основных контрольных точек. Например на имеющуюся карту слоя налагаем добавляемые тайлы с 50% прозрачности - и смотрим глазками на основные схождения, либо автоматизируем еще больше и вычитаем битмапы уже имеющихся тайлов из новодобавляемых, при ГЛОБАЛЬНЫХ различиях - выдаем мессагу чтобы кто-нить из ГомоСапиенсов проверил ручками и глазками.
"Новость" же тайлов определяем только по разнице с CRC с уже имеющимися в базе. Если у новодобавляемого и у уже имеющегося в базе CRC одинаков - такие новые (а по сути - уже имеющиеся в базе) тайлы сразу отправляем в /dev/null, чтобы не хранить ненужных дупликатов по версиям. В базе же делаем симлинк на предыдущую версию или какую другую пометку, что в новой версии именно этот тайл не изменялся по сравнению с предыдущей версией. Если изменялся - ставим не симлинк, а кладем новый тайл (премодерированный ранее).
Чтобы каждый раз не лопатить CRC из имеющихся в базе - можно разово вычислять оный у каждого тайла при добавлении и хранить рядом же, в базе. То есть, юзер прислал тайлы, они проCRCлизовались и легли в спул на премодерацию. Пришел модератор, заапрувил - одинаковые тайлы сразу отсеялись и выкинулись, а именно новые\недостающие - пошли и легли в базу со своими CRC, заодно положив все действия в лог с возможностью отката.
Если модератор не заапрувил - то выкидываем весь пакет из спула, не затрагивая базы.
Проверка же на зоопарк строится при таком подходе и вовсе элементарно: пробегаем по базе по выбранному участку, смотря - какой тайл у нас из всего участка имеет макс.версию (он может быть один более новый тайл на весь староскачанный Зажопинск). Далее вычисляем кол-во необходимых тайлов для апдейта региона на базе самой последней нашей версии, если таковой апдейт необходим. До кучи смотрим, какую макс.версию можно склеить без апдейта но и без зоопарка (последовательно пробегаем по всем нашим версиям от максимальной до первой и смотрим - есть ли где полное заполнение тайлами, например по наличию CRC в базе для всех нужных тайлов). Выдаем юзеру запрос - Обновляем регион до последней версии (нужно укачать N тайлов, времени займет столько-то), либо клеим наилучшую возможную и полную версию (от такого-то числа) без обновления региона? Нужное - подчеркнуть".
Примерно так. Не совсем просто в реализации, но надежность метода на предмет зоопарка лично мне видится довольно высокой. Зоопарк по версиям будет исключен, если только модератор не наапрувит лишнего (но это уже человеческий фактор, а не недостаток метода).