PavelML писал(а):выставляем в САС.планете 13х зум на широте 80 градусов и измеряем встроенным в прогу измерителем расстояний расстояние между крайними видимыми на экране точками. Это фиксированное количество пикселей. Потом делаем то же самое - на экваторе. Получаем в первом случае скажем 12 км, во втором случае - 70 км. В ОДНОМ ЗУМЕ! Это цилиндрическаяя проекция Меркатора.
В посте выше я давал ссылку. Откройте ее и покажите мне "цилиндрическую проекцию меркатора с выставленным в сасе 13м зумом". А я покажу Вам просто тайлы.
Мало? Откройте собственно сабж -
http://www.googleartproject.com и покажите мне геодезию. А я покажу Вам просто тайлы.
Я не зря в предыдущем посте взял определенную сентенцию в квадратные скобки - как раз для этого случая.
PavelML писал(а):звучит слегка по детски. Существует потоковый звук, потоковое видео. Потоковое изображение - теж яйцы, вид сбоку.
Возьмите вышеупомянутый Вами 13й уровень (это 4096х4096, если не ошибаюсь). Покажите мне его на экране мобилы 128\128 с помощью "недетского потокового изображения", заодно обьяснив по пунктам весь процесс? А я Вам расскажу, как этому девайсу отдать максимум 4 тайла в самом сложном случае, даже не прибегая к помощи Апача или иного веб-сервера. А если это 409600х409600 - и клиент не один, а пара-другая сотен тысяч? Ваш вариант просто не будет иметь шансов на существование.
Ну или даже максимально упростим задачу: имеем (в рамках сабжа)
картину с размером оной 65536 x 57344 (3.7Gpix). Расскажите мне за процесс доступа к ней, например, с моего старого
коммуникатора с памятью 58Mb и экраном 240\240? На настоящий момент это делается легко, не нарушая сна и с минимальным траффиком - обьясните, каким образом 3.7Gpix картина живет на 58Мб памяти и не вызывает коматоза всего устройства?
При этом я даже дам Вам фору и не спрошу, как это обеспечится на стороне сервера без открытия этого файла там, ибо у Вас отсутствует понимание разницы
потока (звук, изображение -> от начала к концу по одной дорожке и никак не наоборот, то есть по сути - одномерный вектор) - и
двумерного массива данных с рандомным доступом в любую его часть, чего нет в видео\аудио. Не спрошу, где в "одномерных" видео\аудио находятся индексирующие метки для быстрого доступа в произвольную часть по
одной (временнОй) координате - чего нет в изображениях, тем более сжатых. И также не спрошу, как Вы вообще собираетесь делать произвольный доступ в любую часть сжатого массива данных без собственно его разжатия в нормальный вид и навигации юзера уже по нему. Я даже не намекну Вам, что упомянутое Вами "потоковое изображение" есть вещь статичная и вообще не нуждается в потоковости по своему смыслу. Ну и уж совсем не буду спрашивать об обоснованиях предыдущего Вашего утверждения "
приемлемо - в пределах 256 пикселей", ибо это не то что по детски звучит - а и вообще ни в какие ворота, бо размер пикселей и экранов у всех устройств разный в отличие от аффинных преобразований и прочих проекций. Кому и когда приемлемо - пускай для всех останется загадкой.
Ну и на погоны - обрезка изображения на стороне сервера по размеру экрана клиента есть
вариант тайловости, где задача сводится к вопросу "клиент запросил
один тайл размера Хi\Yi из глобального изображения X\Y", весьма ресурсоемка для сервера, и подходит лишь для относительно небольших проектов с постоянным сервер-сайд рендерингом динамических данных в статику (обычно вектор в растр), что в случае картин мировых классиков, мягко говоря - не в кассу. А некое "недетское потоковое изображение" - есть ничто иное как видео без смены сцены (все кадры=одинаковы), ограниченное со своей стороны уже видеокодеками и по размеру кадра, и по фреймрейту, и вообще.
PavelML писал(а):двоичной арифметики - я ее еще на перфокартах осваивал.
Я вижу. Судя по всему, примерно тогда же всё и закончилось.
Держите матчасть:
Whether you knew it or not, lots of blood, sweat, and tears have gone into making the modern GIMP a tile-based graphics application. And no, that doesn't have anything to do with the "Tile of the Day". What does it mean?
Well, our graphics are two dimensional, but the memory they're stored in is accessed by a one-dimensional index. The usual approach to storing a graphic is to store the whole thing as one long array, stringing one row on after another. This works fine,
until your images get rather large. Say you have a 1000 x 1000 RGBA layer, that takes 4 MB. Drawing a vertical line down the image
requires loading the entire thing into active memory, every row from top to bottom.
GIMP's approach is to break the image up into a series of tiles. Now when you draw that vertical line, o
nly the affected tiles need be in memory.
http://www.gimp.org/docs/plug-in/sect-tiles.html
Еще вопросы? В гугль.
Не успеваем место на дисках под кэш искать, тссссс... 
Весь алгоритм спрятан в swf вьюера сайта, в принципе на различии старой и новой версий вьюера можно дописать свой даунлоадер картин. swf хорошо декомпилируется, но я вообще без понятия что и как там в action script. Нашёл только что генерация урла, вроде как, происходит в MicroscopeUrlFactory.as.