ВОПРОСЫ АБСОЛЮТНЫХ НОВИЧКОВ

[DJ VK]

Выделяю прямоугольником все 3 города и делаю экспорт на 19-м уровне.
Имхо, эти несчастные 2 метра будут экспортироваться часами

Не в о обиду.
Вы сами только что сказали что города три(!). И что невозможно быстро их скопировать. Ведь их же три!!! Надо три раза копировать, три раза создавать полигоны, три раза лелеять снимки и ласкать. Вы ведь сами выбрали эти три региона, а потом словно забыли, что скачали эти кусочки, делаете вид, что у Вас амнезия, и Вам надо целый квадрат-прямоугольник. Сделайте нормальное выделение, благо Вы помните нужные Вам города, соедините их перемычками, если надо 1 выделение (!). И экспортируйте. Вам жалко 5 минут своей работы (хотя суббота была вчера), подождите 5 часов(а лучше бы дней) работы компа - эффективно стимулирует центр борьбы с ленью в голове, знаете ли... А впихать невпихуемое мы еще успеем...

[usver]

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

[Papazol]

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

[usver]

Эта рекомендация хороша, если все выделения нужны в одинаковых масштабах. Однако бывают случаи, когда разные выделения нужны в разных масштабах.
Предположим следующий сценарий - туристическая поездка по стране среднего размера (например, Испании или Франции) на автомобиле с остановками в нескольких (например, пяти) городах на 1-3 дня и пешим осмотром достопримечательностей этих городов. Для такой поездки нужен кэш страны в масштабах примерно 5-14 для переездов между городами и кэши городов в масштабах примерно 15-18 для пеших прогулок. Для выкачивания кэша нужно создать минимум два выделения: одно для всей страны, а второе - полигон с перемычками для пяти городов. Объединить эти два выделения в один файл экспорта для SAS4Android невозможно. Придется создавать два файла экспорта и переключать их при каждом въезде и выезде из города, что довольно неудобно.

[Tolik]

^^^
Да, я обычно так и делаю перед поездками куда-нибудь, только для МЯК. Скачиваю всю страну на мелких зумах + интересующие города, соединённые перемычками - на крупных. Экспортирую в МЯК по отдельности. Благодаря тому, что разные зумы в МЯК хранятся в разных директориях, слить эти кэши получается элементарно.

P.S. Для АБСОЛЮТНЫХ НОВИЧКОВ: квадратные кусочки изображения (как правило, 256х256 пиксел) называются тайлами, а не тайтлами. От слова tile - кафельная плитка, а не title - название.

[Papazol]

Предположим следующий сценарий - туристическая поездка по стране среднего размера

Снимки масштабов 5-14 (может быть 5-13) - это снимки низкого разрешения, по которым ориентироваться на местности не то чтобы невозможно, но трудно. Для этого гораздо лучше подходит карта. А вот для пешего осмотра достопримечательностей как раз лучше снимок (хотя подробная карта тоже весьма не лишняя) . И это разные кэши, переключить которые так легко, что даже не стОит об этом говорить.

[Shoorick]

Кажется я не смог объяснить проблему.
Просьба: когда дойдут руки , сделать перебор при экспорте по файлам в кэше, а не по площадям.

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

По имени тайла в кэше нельзя определить его координаты?
Если можно (и это не сложно), тогда возможно, что последовательное сканирование кэша будет в некоторых случаях оптимальнее. В том числе с точки зрения уменьшения лишних запросов к файловой системе/СУБД.

А СУБД типа Postgres вообще оптимизированы под выполнение таких пространственных запросов по быстрой выборке всех объектов в полигоне.
В MySQL тоже есть пространственные расширения.

[vasketsov]

По имени тайла в кэше нельзя определить его координаты?

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

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

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

В том числе с точки зрения уменьшения лишних запросов к файловой системе/СУБД

Априори нельзя сказать, где будет меньше I/O, меньше время работы, меньше блокировок в случаеконкурентного доступа,... - это всё могут быть разные варианты.

А СУБД типа Postgres вообще оптимизированы под выполнение таких пространственных запросов по быстрой выборке всех объектов в полигоне

Можно ссылку на исходники или маны, где была бы такая оптимизация?
А то наличие расширений для типов ещё ничего не говорит об оптимизации и её качестве.
Хотя если имеется в виду индексирование... ))

В MySQL тоже есть пространственные расширения

Вот это пожалуй более честная формулировка.

[Shoorick]

Да. Например когда тайлов в кэше сильно мало

Кроме того, алгоритм поддается дальнейшей оптимизации.
Для начала, всегда можно вычислить крайние значения x и y для данного полигона (bounding box), и, если кэш структурирован по направлениям x/y или y/x, можно перебирать только определенное подмножество каталогов и имен файлов кэша.

Но в рассматриваемом примере это не так. Потому что в рассматриваемом примере проблема решается...

Не совсем согласен с формулировкой:)
В рассматриваемом примере это так (скорость работы была бы быстрее), но эту проблему можно решить и мультиполигоном/полигоном с перемычками.

Априори нельзя сказать, где будет меньше I/O, меньше время работы, меньше блокировок в случаеконкурентного доступа,... - это всё могут быть разные варианты.

В данном случае, описанном пользователем, очевидно, что 99% времени занимают запросы к диску/базе с ответом "не найдено".

Можно ссылку на исходники или маны, где была бы такая оптимизация?
А то наличие расширений для типов ещё ничего не говорит об оптимизации и её качестве.
Хотя если имеется в виду индексирование... ))

А в чем основания для иронии или слабое место индексирования?
Да, сам я не работал с пространственными СУБД, но знакомые проект делали. Не совсем понимаю, в чем Вы видите слабость таких решений?

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

И еще, пришла аналогия с алгоритмом закрашивания полигона в растровой графике.
Идем сверху вниз и на каждой горизонтальной линии x вычисляем крайнюю левую yl и крайнюю правую yr точки, попадающие в полигон. Остается нарисовать линию x yl - x yr, или просканировать последовательно кэш/базу в каталоге x по именам файлов yl..yr.

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

Впрочем, могу ошибаться, так как не знаю всех нюансов, как там у вас всё организовано.

[vasketsov]

В данном случае, описанном пользователем, очевидно, что 99% времени занимают запросы к диску/базе с ответом "не найдено".

Это проблема неадекватной области выделения. Неадекватной реальным данным. Если бы область выделения была в точности та же, что и для скачки - попадание в БД было бы 100%-ным.

А в чем основания для иронии или слабое место индексирования?

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

в чем Вы видите слабость таких решений?

Я не писал про слабость, я писал, что никаких спецоптимизаций нет. Потому что в реальности это и не требуется.

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

Да. Верно. Более того - копирование части кэша внутри области и работа потом по результирующему кэшу (то есть обратная ситуация) по сути и будет таким индексированием. А в рассматриваемой теме индексированием была бы хранимая карта заполнения. Но это всё нафиг не надо, потому что есть 100%-но идеальный индекс - область выделения.

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