Покуда кэш GC теперь доступен в сасе напрямую, есть одна небольшая тонкость.
По умолчанию в опциях (файл TileCacheRE.ini) правила замены урла примерно такие:
###########################################################
;Сортировка исторических снимков по дате
[RegExpr#11]
Expr=f1-\d+-i\.\d+-(\w+)
Replace=$1\\$0
Active=1
##########################################################
;Сортировка всех данных по уровню зума и подпапкам по 1024 тайла
[RegExpr#15]
Expr=(f1|f1c|q2|qp)-\d+-
Replace=z<Z>\\<Xi>\\x<X>\\<Yi>\\$0
Active=1
Это приводит к тому, что файлы исторического режима сохраняются в папках типа
GeoCacher\cache\Tiles\History\Images\fa88e\z18\84\x86710\42
и в итоге в папке Images подпапками являются даты снимков в hex-представлении.
Если же номер регулярного выражения с 11 заменить скажем на 17, то обрабатываться оно будет ПОСЛЕ сортировки по уровню зума.
Тогда файлы будут сохраняться в папках типа
GeoCacher\cache\Tiles\History\Images\z13\2\x2715\1\faa83
то есть дата снимка уедет в конец.
Это приведёт к тому, что папок будет больше (вместо одной папки с датой будет куча папок с датой по количеству тайлов в снимке*).
Но зато поиск дат (версий) для тайла (а также прочие сопутствуюшие операции типа поиска тайла как такового без даты) будет выполняться СУЩЕСТВЕННО быстрее.
DLL, которая осуществляет доступ к кэшу GC, не разбирает эти регулярные выражения (так как по сути она выполняет обратную операцию), так что она может определить только, до или после xyz находится дата (причём не по ini, а по первой попавшейся папке в кэше с датами).
Так что промежуточные более сложные и в какой-то степени возможно более оптимальные варианты типа
GeoCacher\cache\Tiles\History\Images\<QuadkeyUpTo6chars>\fa88e\z18\84\x86710\42
недоступны. Надо будет что-нибудь придумать на эту тему.
*) точнее тысяч тайлов, так как по умолчанию по Y формируются только "крупные" папки.