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

[Parasite]

Что-то SAS ведёт себя очень странно: режим работы Интернет. Зум=0. Двигаю мышкой карту - SAS начинает бешено грузить:
14!!! запросов по одному URL: http://localhost/get.php?id=0&x=0&y=0&z=0. И SAS пишет "Такого изображения нет на сервере".

Отрицательные значения в запросах - это вообще чо такое?
Врочем, это уже однозначно к feya, имхо...

[zed]

Поставь не прокси, а сниффер. Отключи прокси. Логи сниффера в обоих случаях (когда работает и когда нет) - сюда.

Какой сниффер поставить, чтоб localhost умел снифить?

[Parasite]

Какой сниффер поставить, чтоб localhost умел снифить?

Хм. А в чем проблема любому снифферу прослушать локалхост? Ты, собссно, какой интерфейс сниффаешь - который физический сетевой (например, 192.168.0.1 в подавляющем большинстве дефолтных случаев) или который логический loopback (который и есть localhost ака 127.0.0.1)?
Вот например как переключить сниффер на прослушку loopback в NAI Sniffer Pro 4.60.

PS: ну или например обращаться к своей машине не по "http://127.0.0.1" либо "http://localhost", а по "нормальному" IPy ("http://192.168.0.1" из примера выше)- сетевой интерфейс коего и слушать.

[zed]

Значит так, настроил я локальный HTTP-сервер (пакет Denwer), сделал скрипт get.php, добавил в SAS новую карту с URL http://localhost/get.php?id=0&x=0&y=0&z=0 Видимо проблемы со скриптом: по этому URL браузер уверенно выдаёт картинку (или предлагает сохранить, если в заголовке "Content-Disposition: attachment"). SAS же нивкакую... "Такого изображения нет на сервере"

Код: Выделить всё

header("Content-Disposition: attachment");
header("Content-Length: ".$fsize);
header("Content-type: image/jpg");
print $file;

Собственно, как правильно отдать картинку в SAS?

Нашёл в чём была проблема: Content-type в ответе сервера и в map.ini для данной карты должны строго совпадать. У меня в ini был image/jpeg, а отдавал я как jpg (жипеги )- вот и ругался SAS. Казалось бы, какая мелочь...

[Parasite]

Господа, а пока суть да дело с САСом - не начать ли нам обмениваться кэшем в формате САСа более банальными способами? Например, РАРить соответствующие полностью выкачанные уровни кэша и шарить на том или ином подпароленном обменнике, сугубо для нужд юзеров данного форума? Например, я мог бы поспособствовать с ФТП+местом, и вывалить полностью выкачанные энные уровни из кучки карт, для начала...
Особенно это касается Гугля с его банами и другими проблемами скачки с первоисточника.

[svp]

не начать ли нам

Начать-начать! =)
Кстати, на финальном этапе разработки находится механизм индексации, коий нам здорово поможет в этом деле. Мне так думается.

[Parasite]

не начать ли нам

Начать-начать! =)
Кстати, на финальном этапе разработки находится механизм индексации, коий нам здорово поможет в этом деле. Мне так думается.

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

Имхо придется так или иначе sync'ать с первоисточниками перед выкладыванием (хотя бы по размеру тайла, что ли - уж не до CRC, не до хорошего).

[svp]

Самая главная проблема - это исключить зоопарк тайлов на одном слое.

Да... проблему надо решать.
Есть некоторые наблюдения. Давайте сведём свои знания о снимках в одну кучу. Вдруг придёт светлая идея.

• Насколько я заметил, зоны высокой детализации могут иметь следующие варианты максимальных уровней: 18, 19, 21 и 24. При этом: 21 -- это прерогатива крупных знаменитых городов и достопримечательностей; 18-19 -- стандартные детальные области, как правило покрывают территории областных центров, военных объектов, крупных предприятий, стратегически важных участков (Крым, район курской магнитной аномалии и т.д.); 24 -- это максимальный масштаб очень небольших участков, встречался мной, например, в пустыне Африки, представляет собой привязанные к координатам авиа-фотоснимки.
• Изолированные детальные области 18-х, 19-х масштабов представляют собой как правило нагромождение прямоугольных полосок размерами 70-90 км с севера на юг и 15-18 км с востока на запад. Видимо такая конфигурация отснятой территории связана с траекторией движения спутника.
• Большие детальные участки, как правило, состоят из мозаики разных спутниковых снимков. Отдельные фрагменты мозаики отличаются, само собой, временем съёмки (отсюда разные тени, разная облачность и т.д.), разной обработкой снимков (цветность, цветовой тон, резкость и т.д.). Самый характерный пример такого зоопарка -- это Крым.
• Увидеть действительное расположение снимков мозаики можно начиная с 14 масштаба. Надо полагать, если выкладываются новые снимки местности, то они замещают тайлы с 14-го масштаба по максимальный.
• Так-как многие десятки гигабайт кеша уже выкачаны пользователями и при этом никакого слежения за версиями тайлов не производилось, а Гугл всё сильнее ужесточает политику банов, отказываться от уже выкачанных кешей нецелесообразно. Надёжных способов определять к какой версии принадлежит тот или иной тайл пока не найдено. Предлагаю ориентироваться по датам создания тайлов. Если сохранять все варианты тайлов и их даты, то для каждой версии в будущем каждый сможет определить для себя интервал дат, отфильтровывающий тайды гарантированно одной версии. Недовыкачанные территории старых версий этот метод нам не восстановит, но максимально полно использовать то, что у нас есть и не допустить зоопарка при правильной расстановке интервалов поможет.

В связи с выше сказанным предлагаю:

1. В пакетах, выкладываемых на сайт, стараться размещать полностью выкачанные изолированные участки высокой детализации, причём только максимального масштаба.
2. Участки с тайлами старых версий паковать отдельно с соответствующей пометкой.
3. К пакету прилагать часовой пояс, в котором выкачивались тайлы, и интервал дат создания тайлов.
4. В свете выше сказанного нужна утилита для правильного формирования пакетов. Функционал утилиты обсуждаем.
5. Пакеты по возможности в кучу не сливать и юзать отдельно.
6. Нужен новый формат кеша, который позволит содержать тайлы альтернативных версий с датами создания файлов. Функционал и реализацию нового формата кеша обсуждаем.

[Parasite]

Насколько я заметил, зоны высокой детализации могут иметь следующие варианты максимальных уровней: 18, 19, 21 и 24.

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

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

Минусы:
1. Неизвестны точные рамки жизни той или иной версии тайлов на первоисточнике (и если оные версии не глобальны - то ситуация еще более усложняется в полном соответствии с локальными TTLами). Например, добавление очередного зоопарка у вышеуказанному Крыму - затронет только данный участок, и не приведет ко глобальному изменению номера версии на Гугле, а у нас начнется путаница;
2. Дата создания файлов на диске не гарантирует нужной точности и подвержена тем или иным изменениям со стороны системы юзера

Если опираться именно на даты создания - можно написать прожку, которая будет просматривать дату создания каждого тайла и сравнивать ее с 8ю соседями этого тайла со всех сторон. При глобальной разнице даты создания проверяемого тайла с соседями (например, 1мин) - сигнализировать юзеру о том, что данный файл вероятно - зоопарковый, и выводить ему граф.картину центрованную по данному тайлу, с вопросом - аппрувить ситуацию или нет. Если зумы выкачивались оптом - то таких ситуаций быть не должно даже в теории, если же тайлы выкачивались абы как и когда придется - то у такого кэша будет крайне высокая вероятность зоопарка, и соответственно повышенное число вопросов от валидатора и большее число визуальных проверок юзером (а это кэшу никогда не вредно).

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

• В пакетах, выкладываемых на сайт, стараться размещать полностью выкачанные изолированные участки высокой детализации, причём только максимального масштаба.
• Участки с тайлами старых версий паковать отдельно с соответствующей пометкой.
• К пакету прилагать часовой пояс, в котором выкачивались тайлы, и интервал дат создания тайлов.
• В свете выше сказанного нужна утилита для правильного формирования пакетов. Функционал утилиты обсуждаем.
• Пакеты по возможности в кучу не сливать и юзать отдельно.
• Нужен новый формат кеша, который позволит содержать тайлы альтернативных версий с датами создания файлов. Функционал и реализацию нового формата кеша обсуждаем.

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

Идеи по механизму индексации\проверки кэша на зоопарк - принимаются в ветку круглосуточно.

[svp]

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

Минусы:

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

1. Неизвестны точные рамки жизни той или иной версии тайлов на первоисточнике (и если оные версии не глобальны - то ситуация еще более усложняется в полном соответствии с локальными TTLами). Например, добавление очередного зоопарка у вышеуказанному Крыму - затронет только данный участок, и не приведет ко глобальному изменению номера версии на Гугле, а у нас начнется путаница;

Естественно не известны! Но выбора, опять же, пока что нет.
Проблема с локальными временными зонами отчасти решается обещаниями пользователей прикреплять правильные данные о часовом поясе и поправках локального времени на момент закачки. Аномалии по времени в базе можно уже искать статистически и эмпирически, производя запросы и фильтрации с разными вариантами временнЫх допущений и учитывая различность тайлов.
Главное -- иметь все версии тайлов и не допускать, чтобы внезапно появившиеся новые снимки безвозвратно затирали фрагменты старых снимков создавая зоопарк.

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

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

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

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

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

Идеи по механизму индексации\проверки кэша на зоопарк - принимаются в ветку круглосуточно.

Дабы не быть голословным резюмирую свою идею.

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