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

[Parasite]

А есть вообще возможность определить текущую версию гугла?

Подсмотрев в родные ссылки гугла. Опять же там (скорее всего) меняется не весь движок MapAPI на яве, а скорее всего именно одна из ХМЛок с нач.установками вообще и с версией в частности. Но не уверен. Займусь, разберусь, дам знать.

Не будет ли выходом хранение вместе с тайлом даты его закачки? У файла это дата создания.

Не будет. Одни и те же тайлы можно качать в разное время - как и разные тайлы в одинаковое (многопоточно). Да еще и разницу во времени между юзерами нужно будет принимать ввиду, и девиации и поправки на неточность установленного времени на стороне пользователя...Будет зоопарк, короче.

Зная даты обновлений достоверна ли будет фильтрация тайлов по дате? То есть тайлы закачанные после даты выхода обновления можно ли считать гарантированно новыми?

Выходом будет премодерация новых тайлов на фоне старых, и визуальное совпадение основных контрольных точек. Например на имеющуюся карту слоя налагаем добавляемые тайлы с 50% прозрачности - и смотрим глазками на основные схождения, либо автоматизируем еще больше и вычитаем битмапы уже имеющихся тайлов из новодобавляемых, при ГЛОБАЛЬНЫХ различиях - выдаем мессагу чтобы кто-нить из ГомоСапиенсов проверил ручками и глазками.

"Новость" же тайлов определяем только по разнице с CRC с уже имеющимися в базе. Если у новодобавляемого и у уже имеющегося в базе CRC одинаков - такие новые (а по сути - уже имеющиеся в базе) тайлы сразу отправляем в /dev/null, чтобы не хранить ненужных дупликатов по версиям. В базе же делаем симлинк на предыдущую версию или какую другую пометку, что в новой версии именно этот тайл не изменялся по сравнению с предыдущей версией. Если изменялся - ставим не симлинк, а кладем новый тайл (премодерированный ранее).

Чтобы каждый раз не лопатить CRC из имеющихся в базе - можно разово вычислять оный у каждого тайла при добавлении и хранить рядом же, в базе. То есть, юзер прислал тайлы, они проCRCлизовались и легли в спул на премодерацию. Пришел модератор, заапрувил - одинаковые тайлы сразу отсеялись и выкинулись, а именно новые\недостающие - пошли и легли в базу со своими CRC, заодно положив все действия в лог с возможностью отката.
Если модератор не заапрувил - то выкидываем весь пакет из спула, не затрагивая базы.

Проверка же на зоопарк строится при таком подходе и вовсе элементарно: пробегаем по базе по выбранному участку, смотря - какой тайл у нас из всего участка имеет макс.версию (он может быть один более новый тайл на весь староскачанный Зажопинск). Далее вычисляем кол-во необходимых тайлов для апдейта региона на базе самой последней нашей версии, если таковой апдейт необходим. До кучи смотрим, какую макс.версию можно склеить без апдейта но и без зоопарка (последовательно пробегаем по всем нашим версиям от максимальной до первой и смотрим - есть ли где полное заполнение тайлами, например по наличию CRC в базе для всех нужных тайлов). Выдаем юзеру запрос - Обновляем регион до последней версии (нужно укачать N тайлов, времени займет столько-то), либо клеим наилучшую возможную и полную версию (от такого-то числа) без обновления региона? Нужное - подчеркнуть".

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

[svp]

Не будет ли выходом хранение вместе с тайлом даты его закачки? У файла это дата создания.

Не будет. Одни и те же тайлы можно качать в разное время - как и разные тайлы в одинаковое (многопоточно). Да еще и разницу во времени между юзерами нужно будет принимать ввиду, и девиации и поправки на неточность установленного времени на стороне пользователя...Будет зоопарк, короче.

Вы не правильно поняли идею.
Насчёт временных поясов проблема решается пересчётом на Гринвич, Девиации, думаю, будут незначительными по сравнению с периодом пересъёмки местности и даже вероятным временем с момента выкладывания гуглом новых снимков и началом их закачки. А это значит что бует некоторый запас времени для установки временных фильтров "приблизительно".
Тем более если поставщиком кеша будет Планета, то несложно сделать синхронизацию времени ПК через интернет.
А идея заключается в вот чем. Если известно, что апдейт снимков был произведён гуглом, допустим, 13.03.2007, а затем 15,04.2008, то можно с уверенностью считать. что тайлы, закачанные с 13.03.2007+полдня до 15,04.2008-полдня принадлежат одной версии. Естественно время загрузки тайла надо ставить по синхронизированному через интернет, либо, если есть премодерация, можно поставить дату ручками, зная к какой версии принадлежат модерируемые снимки.

На реализацию возможности премодерации и прочих сложностей сейчас я смотрю весьма скептически. Не потянем, потому что не найдётся достаточно желающих этим заниматься (ИМХО!). А вот сделать простое HTTP-хранилище даже без версий, но чтобы совсем быстро и просто, такое сделать вполне реально и желающие, думаю, найдутся.
Добавить премодерацию и весь Вами описанный функционал к хоть чему-то готовому -- это более вероятно, чем делать СРАЗУ сложную и неповоротливую систему без чёткого ТЗ (а я такое ТЗ писать не берусь). Потому я и исходил сразу из простого компромиссного и расширяемого варианта.
А этот самый простой компромиссный расширяемый вариант состоит в следующем:
1. Загрузка в обменник только отличных от старых тайлов с указанием даты загрузки (по гринвичу из интернета) и ID сессии. Это позволит пока без премодерации по факту осуществлять постмодерацию и удалять разом результаты всей конфликтной секции.
Опять же остаётся вопрос "кому оно надо". Вы помните, что людям нужна планета и кеш для разных целей. Гисовцы рисуют по ним карты, кто-то клеит огромные области, кто-то печатает на стенку, кто-то ездит на машине по снимкам. И ещё не факт, что клеильщики везде главнее всех остальных. На многих- серверах никто не захочет делать премодерацию и следить за контентом. Удалить конфликтную. обнаруженную по факту необходимости, сессию -- тоже вполне конкурентное решение для многих.

Резюмирую.
В любом случае нужны:
-- Регистрация клиентов.
-- Регистрация сессии загрузки территории (пользователь, дата начала аплоадинга, дата конца, ранняя дата загрузки тайла, поздняя дата загрузки тайла, ограничивающий ректангл территории).
-- Точная дата-время закачки тайла с сервиса.
-- Хранение цепочки различных версий каждого тайла.
И это всё сделать совершенно не сложно!
Далее было бы полезным:
-- Возможность постмодерации (просмотр, удаление по отдельности сессий загрузки).
-- Создание модераторами доверительного списка сессий и привязка их к версии сервиса.
Таким образом тот, кому нужно склеить фрагмент без зоопарка, смотрит, есть ли перекрывающие этот фрагмент элементы доверительного списка. Если нет, то лезет и проверяет (модерирует) сессии, пересекающиеся с интересующим его участком.
При этом манипуляций с базой не происходит, всего лишь добавляется в список доверительных сессий новая запись.

Как идея? Не проще ли?

[Parasite]

Насчёт временных поясов проблема решается пересчётом на Гринвич, Девиации, думаю, будут незначительными по сравнению с периодом пересъёмки местности и даже вероятным временем с момента выкладывания гуглом новых снимков и началом их закачки. А это значит что бует некоторый запас времени для установки временных фильтров "приблизительно".

Имхо, термины "я думаю" и "приблизительно" - стоят намного ближе к понятию "на авось", чем термин "двойная перепроверка валидности координат\путей на обоих концах соединения". То есть, при каких-то общих начальных параметрах Ваш способ и будет работать, но ВООБЩЕ - оно слишком зыбко и ненадежно в своей идее. Не хотелось бы ставить колосса на глиняные ноги изначально уже даже на стадии планирования результатов. Лучше ставить его сразу "на бетонные опоры" (то есть заранее проработать функционал в теории и исключить все возможные минусы и гапы) - а потом на практике постепенно идти именно в выбранном направлении.

Всё это понятно, что сразу и в первой же пре-альфе решения - всего запланированного в полной мере не ввести. Но зато будет маяк впереди - как оно все должно работать в финале. К нему и двигаться, пошагово.

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

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

Резюме: я за полную теоретическую проработку функционала (единого и неизменного далее) сразу, и за пошаговое приближение к нему от версии к версии. Небольшие "твики" ожидаемого результата конечно же будут, но именно небольшие и именно твики, а не глобальное изменение того или иного блока программы.

А идея заключается в вот чем. Если известно, что апдейт снимков был произведён гуглом, допустим, 13.03.2007, а затем 15,04.2008, то можно с уверенностью считать. что тайлы, закачанные с 13.03.2007+полдня до 15,04.2008-полдня принадлежат одной версии. Естественно время загрузки тайла надо ставить по синхронизированному через интернет, либо, если есть премодерация, можно поставить дату ручками, зная к какой версии принадлежат модерируемые снимки.

Вот например у меня NTP на раутере закрыт (правило "Запрещено все, кроме того что разрешено"), и нужно открывать порты и синхронизировать время по интернету "на лету" именно для данной задачи. Более того, локальный календарь тут отличается от европейских стандартов, ибо используется не европейский календарь. Соответственно все созданные локальные файлы получают год создания 2551 вплоть до 15 апреля следующего года - когда настанет 2552й год...
Желаете подключить меня к базе? Что-то подсказывает мне, что мои файлы потом еще пятьсот с гаком лет не устареют...

На реализацию возможности премодерации и прочих сложностей сейчас я смотрю весьма скептически. Не потянем, потому что не найдётся достаточно желающих этим заниматься (ИМХО!).

Я готов внести посильную лепту (на премодерацию, а не на написание собственно обработчика всего этого).

Опять же остаётся вопрос "кому оно надо". Вы помните, что людям нужна планета и кеш для разных целей. Гисовцы рисуют по ним карты, кто-то клеит огромные области, кто-то печатает на стенку, кто-то ездит на машине по снимкам. И ещё не факт, что клеильщики везде главнее всех остальных.

Зоопарк может\будет иметь место и при просмотре тоже, ибо база тайлов будет та же самая.

[svp]

To Parasite: Не было и слова сказано по существу идеи постмодерации вместо премодерации. Постмодерация гибче и не обязывает модераторов чего-то фильтровать. Фильтруют и проверяют те, кому оно надо.

[Parasite]

To Parasite: Не было и слова сказано по существу идеи постмодерации вместо премодерации. Постмодерация гибче и не обязывает модераторов чего-то фильтровать. Фильтруют и проверяют те, кому оно надо.

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

[svp]

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

[Alexander]

Не будет ли выходом хранение вместе с тайлом даты его закачки?

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

По поводу битых тайлов, например у меня в кэше нет ни одного битого тайла, ибо каждый из них загружается в JPEGImage/PNGObject для проверки корректности и только после такой проверки на стадии загрузки допускается его использование. JPEGImage borland'ом написан безупречно, и поэтому поддерживает многопоточность во всей её красоте, а вот нормальную реализацию PNGObject я не нашёл и при чтении в сотни потоков некоторые тайлы отбрасываются неправомерно.

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

[svp]

При добавлении нового тайла просмотреть историю в обратном порядке на наличие совпадений (хэш и размер), если совпали то откидываем тайл

Зачем проверять и хеш и размер? Хеша достаточно.
И проблема не в том, как идентифицировать тайлы, а в том, как правильно их расположить в порядке версий сервиса-источника,а также правильно и корректно (без того самого зоопарка) их оттуда выбирать и отфильтровывать. Хотя, ИМХО, это уже лишние заморочки. Однако народ говорит "надо"..

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

Проще в реализации в вашем случае не будет ни сервер ни клиент. Что может быть проще денвера и пары скриптов на php или Perl'е? А app-сервер, да на сокетах, да с закрытым исходным кодом... уж увольте... Кроме быстродействия такой сервер ничего не даст. Однако речи о полной замене локального кеша сетевым, как я понимаю, не идёт. Речь идёт об обменнике. А в этом плане HTTP -- самое оно. Хотя бы потому, что не надо пересматривать политику безопасности сети, открывать дополнительные порты, думать о том, что же там ещё этот закрытый сервер делает...

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

Вот уж с чем соглашусь. И сделать легче и на споры время уходит. Однако иногда всё-таки в спорах что-то рождается.

[Alexander]

Зачем проверять и хеш и размер? Хеша достаточно.
И проблема не в том, как идентифицировать тайлы, а в том, как правильно их расположить в порядке версий сервиса-источника,а также правильно и корректно (без того самого зоопарка) их оттуда выбирать и отфильтровывать. Хотя, ИМХО, это уже лишние заморочки. Однако народ говорит "надо"..

Два инта сравнить быстрее чем 16байт, например по этому. Сначала сравниваем размер, если совпадают, то ещё и хэш.
Думаю по дате легче всего, т.е. в запросе передаётся дата, а потом ищется тайл меньшей ближайшей даты в истории. Даты пишутся сервером в базу, когда тайл добавляется в пересчёте на Гринвич. Если пользователю нужен последняя версия тайла, то программа пересылает текущую дату в системе в пересчёте на Гринвич. Если в системе дата неправильная то пользователь сам виновать, также как если у него часовой пояс неправильно прописан )) Только нужны будут функции сервера по получению всех дат для тайла.

[svp]

Думаю по дате легче всего, т.е. в запросе передаётся дата, а потом ищется тайл меньшей ближайшей даты в истории. Даты пишутся сервером в базу, когда тайл добавляется в пересчёте на Гринвич. Если пользователю нужен последняя версия тайла, то программа пересылает текущую дату в системе в пересчёте на Гринвич. Если в системе дата неправильная то пользователь сам виновать, также как если у него часовой пояс неправильно прописан )) Только нужны будут функции сервера по получению всех дат для тайла.

А как быть, если кто-то залил на сервер сначала новую версию тайлов, а потом кто-то другой залил на то же место старую? Получится же пятно с неадекватными датами тайлов. Откуда серверу знать, когда реально были загружены тайлы?