Глюки в подсчете числа тайлов в произвольном выделении?

[guf]

Включите карту заполнения да посмотрите где чего не хватает (и действительно ли не хватает). Может там tne были?

.tne там нет точно. Сейчас еще раз проверил. Оно даже при выделении другое число тайлов указывает. Возможно грабли с проекцией?

Опять же - включайте карту заполнения и проверяйте визуально.

Карта заполнения не самый лучший вариант.
Давай тогда я по другому вопрос задам:
У меня есть .sdb файл с кешем. Есть архив с беркли с репозитория твоего скаченый полностью еще тогда, когда я в первых тестах участвовал.
В .sdb 1 строка записи = 1 кешу тайла?
Можно ли как то с этим инструментарием (или каким либо еще) посомтреть количество записей в конкретном файле базы? Потому что выбрать листинг нужных файлов и просмотреть это массово уже гораздо проще если с 1 файлом можно так посмотреть.
Ну просто реально, вот у меня sat по области, около 8 миллионов тайлов на нескольких слоях. Я для визуальной оценки себе и людям, кто со мной пользуется этим кешем делал карту заполнения. С чисто тайлового режима предидущая стабильная версия на 21 слое потратила на такую картинку больше суток чтоб я скрин сделал и размер 1 тайла на картинке меньше размера 1 пикселя на экране. Даже просто найти выпадающий из общей массы (случайно пропущеный при скачке тайл) целая проблема, а если делать 2 такие картинки и сравнивать визуально, то это вообще не вариант.
А очень хочется перенести кеш и не побить при этом ничего. Я больше 2-х лет по нужным местам собираю кеш, сейчас то, что у меня есть и что я использую зачастую на сайте отсутствует и если поломается все это то не факт что, например, Parasite захочет и сможет выкачать мне мои десятки гигов из истории GE да и на самом деле не все там и есть что надо.

[zed]

Оно даже при выделении другое число тайлов указывает.

Вот с этим и нужно разбираться в первую очередь. Но к собственно Беркли это отношения не имеет.

Можно ли как то с этим инструментарием (или каким либо еще) посомтреть количество записей в конкретном файле базы?

Можно написать утилиту или встроить прямо в САС некий информер, чтобы выдавал всю подноготную, вплоть до имён тайлов в конкретном файле. Но по-моему это всё равно не вариант.
А как вариант, можно поступить так:
1. Конвертировать тайловый кэш в кэш Беркли
2. Проверить полученный кэш на целостность и восстановить при необходимости (db_verify + db_dump + db_load)
3. Повторить п.1 и убедиться, что в БД уже ничего не записывается, либо, если что-то записалось, то повторить ещё и п.2, а затем опять п.1
4. Теперь можно быть уверенным, что в БД у нас лежит валидный кэш (всё что было в тайловом, есть и в этом). Для супер-полной уверенности, можно распаковать весь кэш Беркли в тайловый кэш в соседнюю папочку и сравнить потайлово с исходным кэшем. На это может уйти не один день и куча дискового пространства понадобится, но коль уж хочется быть уверенным...
5. Не отходя от кассы, создаём бэкапы валидного кэша: разбиваем регион на квадраты и экспортируем их в тайловый или кэш Беркли
6. Полученный бэкап кладём под сукно на чёрный день, а исходный тайловый кэш удаляем и забываем, как страшный сон
7. При повреждении данных с течением времени (а вдруг?) или если вдруг verify начнёт жаловаться, как у меня недавно - пробуем восстановить битый кэш штатными средствами, а для уверенности, после восстановления, можем ещё наверх накатить и бэкап. И вот тут, если что-то из бэкапа запишется в рабочий кэш, мы уже реально увидим сколько тайлов у нас потерялось при сбое.

[guf]

Вот с этим и нужно разбираться в первую очередь. Но к собственно Беркли это отношения не имеет.

Блин. Вот зашел сейчас специально тему найти и перед этим твой ответ увидел. В общем на последней стабильной была проблема сколичеством посчитаных тайлов на этом квадрате при экспорте, но я 6-7 других чисто квадратных выделения перегнал - проблем небыло. Ладно, на обзорной карте потерять немного кеша - чёрт с ним - не умру. Но сейчас вот попробывал выделение по региону сложной форму и всё, трындец. Последняя стабильная версия имеет какой то конкретный глюк с подсчетом кеша, на выделениях сложной формы она считает вообще из головы. Я дико извиняюсь, что засоряю ЭТОТ топик и так до сих пор и не научился пользоваться багтрекером, но... В аттаче выделение. У меня по ниму есть несколько слоев давно уже скаченых и используемых. Сегодня на ночь поставил перегоняться в беркли и вот с утра залез посмотреть результат и обратил внимание на то, что по этому конкретному выделению на 11-16 слоях в сумме в реальности 3869830 тайлов. Если в программу его загрузить для скачивания и сложить сумму по слоям, выходи 9871814 тайла, а если перейти на вкладку экспорта и все 6 слоев пульнуть конвертироваться то на счетчике то 6093062, то 3046231 тайл. Я даже с трудом представляю, что оно там накопирует в беркли в итоге.
И раз уж стал про баги писать, на 2008R2 не работает релиз. Предидущий работал, а этот - нет. И с админпарвами, и с совместимостью с семеркой - вылетает на открытии файлов. Совместимость с ХР СП3 + админправа единственный вариант ее запустить.

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

Про проверку количества тайлов по моему как то наворочено все сильно. В беркли нет мускуловского аналога счетчика записей в таблице? Чем гонять туда-сюда все это не проще ли сделать по схеме
1) конвертирование
2) db_verify + db_dump + db_load
3) сверка счетчика с исходным количеством
4) повторение 1-3 пункта до тех пор, пока не попавшие с первого раза тайлы не попадут в кеш полностью
5) форматирвоание кеша (если конечно в файл они не попадают при добавлении сразу на нужные места и форматирование на лету происходит)

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

[zed]

Конвертировать кэш нужно через опцию Операции - Управление кэшем, тогда и не будет никаких вопросов по регионам и выделениям.

на выделениях сложной формы она считает вообще из головы.

Вы ошибаетесь.

по этому конкретному выделению на 11-16 слоях в сумме в реальности 3869830 тайлов

А вы случаем не путаете, полное число тайлов у вас в кэше с числом тайлов, попадающих в это конкретное выделение? В кэше может быть хоть 100500 тайлов, и это не значит, что все они попадают в этот регион.

а если перейти на вкладку экспорта и все 6 слоев пульнуть конвертироваться то на счетчике то 6093062, то 3046231 тайл.

Почему на вкладку экспорта? На вкладку скопировать же? Или что вы там делаете? И у меня по вашему выделению для 6 слоёв (гугл) для зумов 11-16 показало 18 млн. тайлов. Для одного слоя на z16 (гугл) показывает 2,2 млн. Причём, это число показывает и при попытке загрузить данный регион. Так что, мой совет - разберитесь у себя в голове и сравните показания счётчиков релиза с прошлым релизом, раз уж на то пошло. На одинаковых картах и зумах. И если где-то что-то не сойдётся - в багтрекер.

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

Не надо там пол программы перелопачивать, всё делается довольно легко. Зовите знакомых - пускай пилят.

[guf]

Не было возможности появиться и ответить раньше. Сейчас исправлять буду

Конвертировать кэш нужно через опцию Операции - Управление кэшем, тогда и не будет никаких вопросов по регионам и выделениям.

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

Вы ошибаетесь.

по этому конкретному выделению на 11-16 слоях в сумме в реальности 3869830 тайлов

А вы случаем не путаете, полное число тайлов у вас в кэше с числом тайлов, попадающих в это конкретное выделение? В кэше может быть хоть 100500 тайлов, и это не значит, что все они попадают в этот регион.

Нет, не путаю. У меня на этом выделении есть слой карт. Там, в отличии от спутника, есть все тайлы. Так что открываю выделение в старой программе, беру калькулятор, складываю количество тайлов на всех слоях и сравниваю с реальным количеством в папке -> всегда все совпадало.

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

Вот про что я говорил. Выделение - из предидущего моего поста. 2 проги, "боевой" билд 110418 слева, справа 120808, карта одна и та же, только обозвал по разному в меню. По слоям сравнение количества тайлов в выделении. Разница в 3 раза. В реальности в кеше лежит ровно то количество тайлов, которое показал билд 110418 1:1. Файлов .tne у меня в кеше нет вообще.



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

[Dima2000]

Ради интереса скачал выделение, проверил на САС версии 120819.6313, зум z11 карты гугла.
В области выделения говорит 79*93 (7347) тайлов (ограничивающий прямоугольник), реально скачивается 2393 тайлов, все они идут строго под выделение, ничего лишнего. Все цифры строго правильные. Остальные зумы на взгляд тоже правильно показывается.
Считаю глюка сейчас нету.
А что там показывал и считал релиз более чем годовой давности - никого особо не интересует, может там и был какой-то глюк, давно уже исправленный.

Вот про что я говорил. Выделение - из предидущего моего поста. 2 проги, "боевой" билд 110418 слева, справа 120808, карта одна и та же, только обозвал по разному в меню. По слоям сравнение количества тайлов в выделении. Разница в 3 раза. В реальности в кеше лежит ровно то количество тайлов, которое показал билд 110418 1:1. Файлов .tne у меня в кеше нет вообще.



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

Категорически не согласен, правильные числа приведены в ПРАВОЙ колонке скринов. Скачал всё выделение на z11 и сравнил, ровно 2393 тайла.

[Tolik]

В области выделения говорит 79*93 (7347) тайлов (ограничивающий прямоугольник), реально скачивается 2393 тайлов, все они идут строго под выделение, ничего лишнего.

Так может она должна говорить 2393, а не 7347? Зачем нам число тайлов в прямоугольнике, когда выделение не прямоугольное?

[guf]

Категорически не согласен, правильные числа приведены в ПРАВОЙ колонке скринов. Скачал всё выделение на z11 и сравнил, ровно 2393 тайла.

Справедливости ради скажу, что я на скрине с левым скрином на 11 зумме поторопился, выделение сложное, 20 точек и считает его слегка с задержкой программа, так что на скрине цифра не правильная В жизни там на самом деле 2395 должно быть. Ниже 2 скрина: текущий и предидущий стабильные релиз. И в момент выделения и в момент скачки все заскринено, цифры подчеркнуты. Крайний релиз при открытии выделения считает одно число (ровно по прямоугольнику) а фактически выкачивает другое число (про многограннику). Если проследить мои посты ранее по этому вопросу, то я и спрашивал у zedа о том, сколько реально будет в беркли тайлов при такой работе программы.

В пределах данного топика, воздержусь от дальнейшего обсуждения количества тайлов по вашему выделению. Если хотите разобраться и считаете, что тут присутствует баг - пишите в багтрекер http://sasgis.org/mantis/

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

п.с. Прикреплены 2 скрина, атм видно номера сборок и цифры. Сборки чистые, из недавно опубликованной новости с архивом релизов скачены, в каждой только 1 GoogleMap.zmp с 183 версией карт и абсолютно идентичный в обоих случаях.

крайний релиз

предидущий релиз

Старая версия скачала 2395 тайлов, новая версия 2393 тайла. Число 2395 мне так же показали все имеющиеся у меня (в архиве местном) стабильные релизы кроме крайнего, из чего делаю вывод, что не правильно считает крайний релиз.

количество тайлов в кеше

И в заключении обе карты заполнения. На карте с крайней версией 120808 я визуально нашел 2 отсутствиующих тайла и стрелочкой их отметил:

110418 заполнение

120808 заполнение

[Dima2000]

В области выделения говорит 79*93 (7347) тайлов (ограничивающий прямоугольник), реально скачивается 2393 тайлов, все они идут строго под выделение, ничего лишнего.

Так может она должна говорить 2393, а не 7347? Зачем нам число тайлов в прямоугольнике, когда выделение не прямоугольное?

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

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

Зря вы так. Как раз последняя ночная сборка (а вовсе даже не релиз от 8-го августа!) считает более правильно, 2393 тайлов. Вдемидов что-то там много исправлял в карте заполнения и проекциях около 20-го августа. Так что проверяйте на последних ночных сборках, а предыдущие релизы не есть эталон качества, к сожалению.
Собственно, мы отклонились от темы. Если считаете что в программе глюк с обработкой выделения - это в другую тему. Надеюсь модераторы отрежут.

[zed]

Крайний релиз при открытии выделения считает одно число (ровно по прямоугольнику) а фактически выкачивает другое число (про многограннику).

Точно так же будет работать и экспорт в Беркли (и любой другой, к примеру, в tar или zip) - по многоугольнику.

Старая версия скачала 2395 тайлов, новая версия 2393 тайла. Число 2395 мне так же показали все имеющиеся у меня (в архиве местном) стабильные релизы кроме крайнего, из чего делаю вывод, что не правильно считает крайний релиз.

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