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

[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, формально не является разрежённым хранилищем, он является почти пустым хранилищем, и оптимизация реализуется самым обычным индексом.

[Shoorick]

Основание для иронии - считать индексирование специальным способом оптимизации.

Хорошо, я имел в виду, что СУБД с пространственными расширениями (специндексами, функциями и запросами) в данном конкретном случае сразу, из коробки дает пользователю возможность оптимально выполнять такие запросы, в том числе на разреженных данных. Запрос "выбрать объекты внутри полигона" - наверное, один из самых, если не самый типичный.

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

Более того - копирование части кэша внутри области и работа потом по результирующему кэшу (то есть обратная ситуация) по сути и будет таким индексированием.

Не понял.

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

Ну а я иногда выкачиваю снимки береговой линии. Снимок моря тоже интересен и важен, так как там могут быть камни и мели. Они могут уходить и далеко. Однако сервисы предпочитают на некотором, заранее неизвестном, расстоянии от берега обрывать область хорошего разрешения. В результате заранее выделить полигон, в котором будет 100% данных, практически невозможно.

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

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

[vasketsov]

Более того - копирование части кэша внутри области и работа потом по результирующему кэшу (то есть обратная ситуация) по сути и будет таким индексированием.

Не понял.

Я о разнице между вариантами:
1. Есть произвольный кэш, выделяем произвольную область, работаем с ней.
2. Есть произвольный кэш, выделяем произвольную область, переносим её отдельно, работаем со всей перенесённой областью без использования области выделения.
Так вот случай 2 с точки зрения операций над кэшем фактически раносилен актуальному кластерному индексу над случаем 1.

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

Если в кэше будет сохранться TNE - попадание в индекс будет 100%-ным, ибо NULL или TNE в качестве тела тайла - это тоже данные. Причём в индекс они попадают на любой из поддерживаемых СУБД, если говорить про СУБД. Не попадание в индекс будет в том случае, если координата отсутствует в индексе, то есть если нет тайла и нет TNE.

Согласен, но геоданные по своей природе очень часто разреженные (если хотите, называйте их "почти пустыми", мне непринципиально)

Давайте я попробую объяснить разницу. Ибо с точки зрения хранилища и индексирования она принципиальна:
1. Если TNE сохраняется, и тайла нет, то в хранилище есть об этом запись. Так как все поля в первичном ключе (координаты тайла) не NULL, то на любой СУБД такая запись попадает в индекс. Соответственно используя этот индекс, можно быстро найти адрес, где физически хранится тело тайла. Обнаружим мы там реальный тайл или NULL - индексу совершенно по лампочки, потому что поле "тело тайла" очевидно само по себе не входит в первичный ключ и вообще не индексируется. Это конечно несколько упрощено, хотя бы исходя из наличия покрывающего индекса над первичным ключём. Но суть вполне отражает. Так вот разреженным хранилищем называется такое (возвращаясь к нашим баранам), где записи TNE есть, и их много, то есть в поле "тело тайла" очень много значений NULL. В этом случае имеет смысл хранить записи с NULL и не с NULL по-разному, чтобы не ходить лишний раз по индексу и тратить меньше места на хранение пустого поля. В этом и заключается оптимизация sparsed storage.
2. Если TNE не сохраняется, и тайла нет, то в хранилище нет об этом записи. Соответственно такая отсутствующая запись гарантированно не попадает ни в какие индексы, просто потому что невозможно предусмотреть логику предметной области: БД не знает, какие вообще могут быть записи внутри неё. Поэтому БД не может сделать никаких предположений о тайлах и TNE, которых у неё нет. Соответственно хранилище знать не знает, что оно не заполнено, и что там есть пустые места. Я это назвал "почти пустым", хотя специального названия такой ситуации нет (и уж точно это не разреженное хранилище), так как оно просто не нужно. Это самая обычная рабочая ситуация, и никакой оптимизации в хранении тут быть не может по определению: мы не знаем, что через секунду может упасть в БД, и как потребуется это "переоптимизировать". Соответственно в индекс отсутствующие записи не попадают, значит по индексу СУБД не сможет определить, где хранится то, чего нет (более того, даже индекс может быть неактуален из-за протухания статистики, так что всё ещё хуже чем могло бы быть).

[Tolik]

Ну вы и забрались в дебри, "абсолютные новички".