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

[vdemidov]

Ну не скажи. Менять придется хотя бы для возможности работать с версиями тайлов. Я уже писал, что желательно что бы автор работу с базой вынес на уровень плагинов, тогда вообще было бы хорошо.

[Parasite]

Битые и несоответствующие CRC файлы в кеш сохранять не следует ни при каких обстоятельствах.

Как собираемся отличать битый от небитого? Не забываем, что качать с гугля будет локальный САС, и отправлять в глобальную базу будет уже он, а не гугль. Соответственно база НИКАК не узнает, правильно ли скачан файл на участке "гугль->САС", если сам САС прямо не скажет этого на участке "САС->база".

Если косячит алгоритм закачки и неправильно именует тайл, то эта проблема к версии относится слабо.

Зато это очень относится к базе - когда "первый же залетевший глючный дятел разрушит цивилизацию"©

Если версий не учитывать вовсе, то старого варианта не останется и придётся перекачивать ошибочные участки. С версией (по приведённой выше схеме) достаточно удалить тайлы косой версии в локально накосяченом участке.

Как будем отличать кривой участок от правильного - при общем кол-ве тайлов, например, в миллион? Глазками смотреть?? Увольте...

Опять же можно строить тайлы карты заполнения с учётом версий и быстро находить потенциально битые участки по номеру версии.

Если посреди Садового Кольца вкрячатся тайлы озера Титикака (и сами тайлы будут верными и не битыми) - то НИ ОДНО заполнение слоя тебе не покажет ошибки. А она будет.

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

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

Чтобы лог не достиг эпических размеров определить понятие сессии и запись тайлов производить в пределах этой сессии. Логировать. соответственно, сессию вместе с баундами, в пределах которых аплоадились тайлы в этой сесссии.

И что Вам дадут логи? Косяк-то может вскрыться и через год, и через десять (пока его визуально не заметят).

Именно так. Даже если тайлы на гугле не отличаются от старых, версия их уже новая. Хранить много копий одних и тех же данных нерационально. Версии же нужны. Например недавно (в пределах нескольких месяцев) обновились детальные снимки Парижа. Причём старые снимки были качественнее и с лучшей цветопередачей. Они лучше годились для печати. Были просто красивее. По данным с гугла отличить старые это тайлы или новые, по ходу, никак нельзя.

Кто-то из предыдущих ораторов в какой-то из веток писал, что Гугль собирается публиковать список произведенных апдейтов.

При отсутствии параметра "v", повторюсь, выдавать тайлы максимальных версий. При указании конкретной версии следует выдавать тайлы с версиями НЕ БОЛЬШИМИ указанной. То есть, если нет тайла с указанной версией, то выдаём тайл с ближайшей меньшей версией.

Пример:
1. Москау смотрят\выкачивают\докачивают в базу 10 раз\сут, последняя "наша" версия, к примеру - 1000.
2. Соседний с ним Зажопинск единожды выкачал единственный живущий там пионер 1раз 10мес назад, последняя наша версия - 1.
3. Клея картинку из стыка пунктов 1 и 2 - берем тайлы макс.версий с обоих и получаем зоопарк на стыке, которого не будет если клеить напрямую с гугля.

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

Ещё раз: битые и косые тайлы не помещаем в кеш.

Алгоритм отличания битого жпега от небитого - в студию. И уж тем более косого - от некосого.

По-хорошему, надо бы передавать вместе с тайлом еще и реальные координаты откуда он был выкачан САСом, и в базу класть согласно соответствия вычисленного САСом локального кэш-пути (или еще какого-нибудб CRC, привязанного к кэш-пути ПОСЛЕ скачки) и переданных САСом координат, которые были ДО скачки. И перепроверять на стороне базы. Если совпали - то класть в базу, если нет - то безусловно отправлять принятое в /dev/null
Правда от ботов и специально запрограмированной подмены это не застрахует. Плаааавно приходим к необходимости криптования....

Если они туда как-то попали, их надо оттуда вычищать.

Кто и как будет этим заниматься?

Я там выше дважды писал,

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

при запросе тайла i-ой версии сервер должен возвращать тайл с максимальной версией, но меньшей либо равной i. То есть Зажопинск будет виден наравне с Москвой.

...и если гугль у себя менял этот регион - то мы у нас получаем кусок свежей, недавно выкачанной другими Москвы и старого, выкачанного единожды год назад Зажопинска, то есть == зоопарк.

Проблема может возникнуть только для сформированных слоёв. Однако в правилах сервера следует запретить закачку на него сформированных слоёв. Формировать слои должны админы.

При слоях с зумом =>5 прочекать всё глазками становится крайне затруднительно, и чем дальше в лес - тем толще партизаны. На каком-то этапе длительность "формирования слоя админами" становится сравнимой с закачкой этого слоя (последней версии и проапдейченного!) с нуля с гугля. Например, 12й зум Земли у меня закачался за полдня. Если бы я его верифицировал глазками - я даже не знаю, сколько времени у меня это бы заняло...

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

Надо просто сделать пре-модерацию закачиваемого в базу (не всех слоев админами, а только новозакачанного). Например, такой-то юзер хочет покласть в базу половину Москвы: не вопрос, кладет во временный спул, потом приходит злобный админ и налагает этот спул на уже имеющийся предыдущий слой. Если визуально оно сходится = то аппрув. Если есть глобальные различия - то перепроверка, перекачка итд. То есть - обычная премодерация сообщений (в данном случае - пакетов аттачей в базу). Разовая премодерация будет немного весить - зараз одним юзером можно выкачать не так уж и много, как мы знаем...
PS: И сделать возможность откатов аппрувленных пакетов - а то единственный пьяный пивом админ может крайне много чего наапрувить...
PPS: и все это делается на server-side стороне путем тех или иных обработчиков на пхп\перле. Код САСа менять придется только раз - на тему ориентирования ее на серверную базу, а не на локальный кэш.

[svp]

Народ! Давайте определимся сперва, о чем идёт речь. Что это за HTTP сервер, для чего он и т.д.
Совершенно незачем писать второй гугл. Я уж не говорю о том, что такой плагиат незаконен и неэтичен. Речь идёт о маленьком локальном сервере в локальной сети или даже в интернете, но этот сервер никак не должен затачиваться для массового потребителя. Никакой речи об афишировании нет. Сами понимаете, что будет иначе.

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

Как собираемся отличать битый от небитого?

Также как отличаете битые тайлы в своём кеше Вы сейчас. Сервер тут ни при чем.

Если косячит алгоритм закачки и неправильно именует тайл, то эта проблема к версии относится слабо.

Зато это очень относится к базе - когда "первый же залетевший глючный дятел разрушит цивилизацию"©

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

Как будем отличать кривой участок от правильного - при общем кол-ве тайлов, например, в миллион? Глазками смотреть?? Увольте...

Вы сейчас глазами смотрите? Кому надо тот свой участок посмотрит. Чего Вы ждёте от обменника? Искусственного интеллекта?

Если посреди Садового Кольца вкрячатся тайлы озера Титикака (и сами тайлы будут верными и не битыми) - то НИ ОДНО заполнение слоя тебе не покажет ошибки. А она будет.

Нарочно искать ошибки никто не будет. Если Вы решили склеить садовое кольцо, то Вы окинув его взглядом узрите воды Титикака. Есть два варианта:
1. При скачке тайлов Титикаки у кого-то что-то проглючило и они отправились по другим координатам в кеш Москвы. Тогда у этих тайлов будет версия на 1 большая чем версия нормальных тайлов Москвы. Тут нам поможет карта заполнения.
2. При закачке Москвы алгоритм глючил и некоторые тайлы были взяты не оттуда. Тогда у всех тайлов версия одинакова и Вам тут ни в локальном кеше ни в серверном ничто не поможет. Эти тайлы надо удалять вручну. И удалять их будет тот, кому надо иметь нормальную карту Москвы. Никто, естественно, не будет назначен ассенизатором.

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

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

И что Вам дадут логи? Косяк-то может вскрыться и через год, и через десять (пока его визуально не заметят).

Согласен. Лог пока не нужен. Хотя проблемного клиента в домашней сети найти можно было бы. Тем более, если лог вести в БД и фильтровать по базе. Можно хоть убрать разом все тайлы, закачанные этим юзером.

Кто-то из предыдущих ораторов в какой-то из веток писал, что Гугль собирается публиковать список произведенных апдейтов.

Вроде публикует. Пишет названия городов. Это не годится.

Пример:
1. Москау смотрят\выкачивают\докачивают в базу 10 раз\сут, последняя "наша" версия, к примеру - 1000.
2. Соседний с ним Зажопинск единожды выкачал единственный живущий там пионер 1раз 10мес назад, последняя наша версия - 1.
3. Клея картинку из стыка пунктов 1 и 2 - берем тайлы макс.версий с обоих и получаем зоопарк на стыке, которого не будет если клеить напрямую с гугля.

Вы не поняли. Версия тайла увеличивается не при каждом аплоадинге, а при каждой загрузке на сервер тайла отличного от стоявшего уже по этим координатам. То есть по сути мы сверху того тайла положим ещё один. Говоря о показе тайлов с параметром v=3 мы имеем виду. что надо показать тайлы не выше третьего. То есть если он был один, то с него и снять нечего.
Если же гугл обновлял москву чаще Зажопинска, то между ними и будет зоопарк. Посмотрите на Крым в 14 масштабе, зоопарк тот ещё. И никуда от него не деться. А если Зажопинск -- сателлит и обновляется вместе с Москвой, но новую Москву уже залили на сервер, а Зажопинские тайлы старые, то тоже делать нечего. Кому не нужен зоопарк, тот подкачает Зажопинск. Как это происходит и сейчас в локальном кеше. А если между закачками Зажопинска на москву положили уже два слоя, то извиняйте. Промежуточного Зажопинского слоя уже нет и не найти. В общем это уже частный случай и проблема именно тех. кому не нужен зоопарк. Версия по крайней мере не даёт теряться закачаным ранее тайлам после обновления снимков гуглом. Я очень жалею, к примеру, Парижские снимки. Сейчас на их месте какая-то желтая хрень.

Старый

Новый

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

Ещё раз: битые и косые тайлы не помещаем в кеш.

Алгоритм отличания битого жпега от небитого - в студию. И уж тем более косого - от некосого.

Это проблемы САС, а не сервера. Вы же сами сказали. Да и к чему придирки7 Всего не предусмотришь и не автоматизируешь. По-любому что-то придётся делать ручками. И делать будет тот кому оно надо.

По-хорошему, надо бы передавать вместе с тайлом еще и реальные координаты откуда он был выкачан САСом, и в базу класть согласно соответствия вычисленного САСом локального кэш-пути (или еще какого-нибудб CRC, привязанного к кэш-пути ПОСЛЕ скачки) и переданных САСом координат, которые были ДО скачки. И перепроверять на стороне базы. Если совпали - то класть в базу, если нет - то безусловно отправлять принятое в /dev/null
Правда от ботов и специально запрограмированной подмены это не застрахует. Плаааавно приходим к необходимости криптования....

Надо от простого к сложному. К чему сейчас без толку говорить, когда нет ещё НИЧЕГО.

Если они туда как-то попали, их надо оттуда вычищать.

Кто и как будет этим заниматься?

Тот, кому это надо. Как? Хранение разных версий тайлов, голова на плечах и форум ему помогут.
Мы делаем не коммерческий проект, а открытый и полулегальный,держащийся на одном лишь энтузиазме. Никаких гарантий.

при запросе тайла i-ой версии сервер должен возвращать тайл с максимальной версией, но меньшей либо равной i. То есть Зажопинск будет виден наравне с Москвой.

...и если гугль у себя менял этот регион - то мы у нас получаем кусок свежей, недавно выкачанной другими Москвы и старого, выкачанного единожды год назад Зажопинска, то есть == зоопарк.

Я выше уже ответил на это. Проблема есть только если Зажопинск обновлялся гуглом вместе с Москвой дважды, а выкачан, в отличие от Москвы, был единожды. И это проблемы не сервера, а того, кому нужна картинка без зоопарка. Самую свежую версию всегда можно сделать ровной (без зоопарка) прокачав всю недостающую территорию. Но если у нас зоопарк на нижних слоях, то ничего уже не поделаешь. Разве что писать письмо в гугл, чтобы прислали старый Зажопинск.

При слоях с зумом =>5 прочекать всё глазками становится крайне затруднительно...

Всё верно. Поэтому чекить будет каждый себе кому что нужно. Или наймём Китацев? Или напишем ИИ? Есть разумные варианты?

Надо просто сделать пре-модерацию закачиваемого в базу

Надо просто не расшаривать сильно сервер. Иначе его посетят проблемы почище юзеров.

PS: И сделать возможность откатов аппрувленных пакетов - а то единственный пьяный пивом админ может крайне много чего наапрувить...
PPS: и все это делается на server-side стороне путем тех или иных обработчиков на пхп\перле. Код САСа менять придется только раз - на тему ориентирования ее на серверную базу, а не на локальный кэш.

Ага. Только это всё делать надо когда хоть что-то заработает. А там может и необъодимость отпадёт.
И вообще. Хватит словоблудить. Конкретно и по пунктикам сочиняем ТЗ. Кто с чем конкретно не согласен и имеет альтернативные предложения, то пишем кратко и по существу. Воздержимся от предложений типа "скинемся и купим гугл" или "это всё херь, надо писать ИИ" или "не так, но не знаю как".

[Parasite]

В свете всего этого, уважаемый Parasite, пересмотрите, пожалуйста, свои возражения.

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

Как собираемся отличать битый от небитого?

Также как отличаете битые тайлы в своём кеше Вы сейчас.

Сейчас я их не различаю. Если файла нет - он качается САСом, если он есть - он показывается, если он есть и битый - он еррорится тем же САСом в виде серого квадрата при просмотре именно этого тайла и не ранее.
Дело же в том, что например при склейке карты я не всегда могу\хочу проверять визуально ее всю на нужном мне зуме - мне достаточно выбрать ее границы на зуме Х, но указать склеить зум Y (который уже может быть крайне обьемным). Проверять же весь зум Y визуально мало того что нет желания - так еще и займет время.

Если косячит алгоритм закачки и неправильно именует тайл, то эта проблема к версии относится слабо.

Зато это очень относится к базе - когда "первый же залетевший глючный дятел разрушит цивилизацию"©

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

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

Как будем отличать кривой участок от правильного - при общем кол-ве тайлов, например, в миллион? Глазками смотреть?? Увольте...

Вы сейчас глазами смотрите? Кому надо тот свой участок посмотрит. Чего Вы ждёте от обменника? Искусственного интеллекта?

Ваша версия выслушана и понята, спасибо.
PS: Намного более надежный способ (с перепроверкой на стороне базы) предложен постом ранее - кому нужно, тот возьмет на вооружение. И токи да - я был бы крайне рад, если бы в САСе вдруг появился ИИ (но ввести его сам не возьмусь, и не предлагайте ).

Если посреди Садового Кольца вкрячатся тайлы озера Титикака (и сами тайлы будут верными и не битыми) - то НИ ОДНО заполнение слоя тебе не покажет ошибки. А она будет.

Нарочно искать ошибки никто не будет. Если Вы решили склеить садовое кольцо, то Вы окинув его взглядом узрите воды Титикака.

Пожалуйста, окиньте мне вглядом карту мира на, например, 15м зуме на предмет несоответствий - и за вменяемое время скажите, где там несоответстия и какие конкретно тайлы мне необходимо перекачать?? Сказать, сколько тайлов на карте 15го зума?
PS: У меня есть такая карта в Zoomify. Окидывать Вам придется крайне долго, уверяю Вас...

1. При скачке тайлов Титикаки у кого-то что-то проглючило и они отправились по другим координатам в кеш Москвы. Тогда у этих тайлов будет версия на 1 большая чем версия нормальных тайлов Москвы. Тут нам поможет карта заполнения.

Дак и у нормальных свежеукачанных тайлов Москвы ТОЖЕ будет версия на 1 больше, чем у базиса - если они туда когда-то польются, например, другим юзером. И весь вопрос - именно узнать, что в тайлах по факту - Москва или Титикака. Либо проверить "руку дающую" на своей стороне - а не Титикаку ли ты мне пытаешься влить во МКАД, а?
Либо я Вас не понимаю.

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

Поэтому ни о какой открытой базе речь не идёт.

Насколько я помню топикстартер - тут витала идея именно об обмене кэшем через какое-то централизованное хранилище (ФТП, HTTP или базовод - дело уже десятое). Если данное хранилище не расшаривать - то идея теряет смысл. Как обмениваться - дампами базы по мылу что ли? Не проще ли тогда утаптывать в TrueCrypt и обмениваться уже ими? И менять в САСе ничего не надо, и гугль обломает зубки при попытке проверки содержимого...

Вы не поняли. Версия тайла увеличивается не при каждом аплоадинге, а при каждой загрузке на сервер тайла отличного от стоявшего уже по этим координатам. То есть по сути мы сверху того тайла положим ещё один. Говоря о показе тайлов с параметром v=3 мы имеем виду. что надо показать тайлы не выше третьего. То есть если он был один, то с него и снять нечего.

Хорошо. Ситуация для отработки:
1. Москау, популярное место - есть все версии к.тайла от 1 до 10, последняя выкачана час назад.
2. Зажопинск, есть единственная версия к.тайла нумба 1, выкачана год назад.
3. Весь регион (Москау + Зажопинск) обновлялся пару раз за этот год.
4. Клеим\смотрим карту, включающую оба города. Получаем ЛИБО старую карту Москау v.1 + текущую Зажопинска v.1 из базы (если брать по наименьшей доступной версии базы), ЛИБО новую карту Москау v.10 + пустой квадрат v.10 на месте Зажопинска (если брать по наибольшей доступной версии базы), ЛИБО зоопарк из новой Москау v.10 и старого Зажопинска v.1 на одном листе (причем не факт, что место стыка будет визуально прямолинейно, а не 5 тайлов туда\тайлов сюда и в шахматном и каком угодно другом порядке).
При клеиньи\показе же с гугла этого всего не будет. Это как раз то, что я и имел ввиду уже третий пост подряд.

Кому не нужен зоопарк, тот подкачает Зажопинск.

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

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

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

В общем это уже частный случай и проблема именно тех. кому не нужен зоопарк.

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

Ещё раз: битые и косые тайлы не помещаем в кеш.

Алгоритм отличания битого жпега от небитого - в студию. И уж тем более косого - от некосого.

Это проблемы САС, а не сервера. Вы же сами сказали. Да и к чему придирки? Всего не предусмотришь и не автоматизируешь. По-любому что-то придётся делать ручками. И делать будет тот кому оно надо.

1. Это проблемы законченного комплексного решения, коль скоро оное в стадии "проектирования". Если будет необходимо вмешиваться в код САС - то не учесть ли и это сразу, и заранее предотвратить грабли в будущем?
2. Какие придирки? Идет живое обсуждение "техпроекта". Оффтоп в сторону - выявляем грабли, обсуждаем и стараемся не наступить на них, засим всё.
3. Если львиную долю работы придется делать ручками и каждому (тому кому оно надо) - то каков смысл во всей затее? На настоящий момент всё именно так и есть - кому что надо, тот то и делает ручками. Я конверчу в зумифай сторонним скриптом, zed юзает HC вместо базы, Вы храните(?) старые снимки Парижа, кто-то еще - тоже чем-то занят. Смысл затеи с базой? Плюсы каковы? Шарить мы не готовы, автоматизировать на полную - тоже, отслеживать валидность карт ручками - ни у кого времени нет, итэдэ итэпэ.....

Если они туда как-то попали, их надо оттуда вычищать.

Кто и как будет этим заниматься?

Тот, кому это надо. Как? Хранение разных версий тайлов, голова на плечах и форум ему помогут. Мы делаем не коммерческий проект, а открытый и полулегальный, держащийся на одном лишь энтузиазме. Никаких гарантий.

Идеалов не существует - но к ним надо стремиться ©

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

То есть, Вы предлагаете отслеживать гуглеверсии территорий заинтересованным в оных (ручками и глазками), а не самой программой - одновременно таки предлагая менять саму программу и вводя базовод? Ввах..... Эту задачу я могу делать банальным ВебсайтВотчером вот прямо сейчас - запрограммировав его выкачивать один из жпегов по центру нужной мне территории на нижнем уровне пару раз в час, и уведомлять меня если размер файла изменится (либо еще хлеще - по факту нахождения изменения жпега запустить тот или иной скрипт, кой и вынет мне всю обновленную заранее сконфигуренную территорию на диск в отдельную папочку)..... Только вот смысл столь глобальной переработки САСа тогда в чем, если по-прежнему всё надо будет делать самому и сторонними тулзами? Сторонними инструментами я это могу делать хоть сейчас...

При слоях с зумом =>5 прочекать всё глазками становится крайне затруднительно...

Всё верно. Поэтому чекить будет каждый себе кому что нужно. Или наймём Китацев? Или напишем ИИ? Есть разумные варианты?

Есть. Поиск по предыдущему посту на слово "премодерация".

Конкретно и по пунктикам сочиняем ТЗ. Кто с чем конкретно не согласен и имеет альтернативные предложения, то пишем кратко и по существу.

Выше. Можете подумать пока что по озвученному - как мы все с этим будем жить и как мы это будем обходить.

[svp]

Короче спорить я не буду. Про версии тайлов меня не поняли и понимать, видимо, не желают.
Хорошо.
Я было выдвинулся как-то координировать проект (никто, ведь, больше не выдвигался), но так у нас ничего не выйдет.
Уважаемый Parasite, набросайте план реализации http-сервера для обмена кешем. Выделите там этапы, первоочередные задачи и всё такое. Ну чтобы понятно было как делать. Иначе с мёртвой точки дело не сдвинется.

[vdemidov]

Пока IMHO не до конца ясно что должен уметь сервер начинать что-то делать конкретное рановато. Нужно что бы автор программы выразил свое мнение, ибо ему это добавлять в программу. Или что бы вынес работу с базой, не важно локальной или серверной, в отдельный плагин, но это опять же от него зависит.

[Parasite]

Короче спорить я не буду. Про версии тайлов меня не поняли и понимать, видимо, не желают.

1. От отказа в обсуждении проблемы - сама проблема не исчезает, к сожалению. Следующий за Вами оратор наткнется на те же самые грабли при проработке той же самой идеи.
2. Про "не поняли и не желают" - ниасилил, извините. Проблема имеет место быть, описана в "контрольном примере" постом выше (про Москву+Зажопинск), внятного предложения решения проблемы ни от кого пока что не поступило. На мой взгляд, отрыв "наших" версий от привязки к действительным гуглеверсиям на исходном сервере есть крайнее зло (почему - подробно описал в постах выше). Причем тут "Вас не желают понять"? Ведь даже соседний оратор в этой же теме указывает на возможные глюки на "границах версий" при сведении - ибо это действительно очевидно. Если считаете свою версию развития событий истинно верной - решите, пожалуйста, "контрольный пример" с выкладками в студию.

Уважаемый Parasite, набросайте план реализации http-сервера для обмена кешем. Выделите там этапы, первоочередные задачи и всё такое. Ну чтобы понятно было как делать. Иначе с мёртвой точки дело не сдвинется.

Пока что непонятен сам смысл затеи, если изначально не ориентироваться на многопользовательский доступ, хотя бы и в отдаленном будущем. Скажите, пожалуйста - зачем нужна заморочка с сервером и базой, если все это великолепие (с потенциально огромными возможностями в истинно многопользовательской среде) ориентировать только под локалхост и единичного пользователя? На пару-тройку пользователей уже существующий локальный кэш преспокойно можно расшарить любым софтовым НАСом, да и хотя бы тупо зашарить ТруКриптовый контейнер средствами шаринга дисков самой винды...
От данного ответа и надо будет плясать. Городить же огород ради мега-версии САСа, но нужной всего лишь двоим-троим (или сколько нас тут активных) ценителям вопроса - просто экономически и логически невыгодно. Времени и сил уйдет КУЧА, а результат для 99% пользователей САСа окажется по большому счету совершенно не нужен.

[svp]

А есть вообще возможность определить текущую версию гугла?
Кроме гугла на других сервисах версии определяются и аналогичным ли образом?
Указав в запросе старую версию, мы получим старые тайлы?
Или версия в звпросе нужна только чтобы бороться с кешированными в браузере тайлами?
Не будет ли выходом хранение вместе с тайлом даты его закачки?
У файла это дата создания.
Зная даты обновлений достоверна ли будет фильтрация тайлов по дате?
То есть тайлы закачанные после даты выхода обновления можно ли считать гарантированно новыми?

[vdemidov]

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

[svp]

А как бы так проверить по пунктикам всё. Это важно. Может быть удастся не затратив труда добиться того самого отсутствия зоопарка, что так нужно Parasite.