kealon(Ruslan)д0kЯ думаю что из готовых известных мне архитектурно алгоритмических
вариантов представления
z-кривая будет лучшим выбором , если пренебречь тем что Земля не шар, а геоид.
Как выстрелит эта погрешность я не знаю.

тут проблема в том, что желательно что бы все точки "поискового прямоугольника" выпадали на один интервал Z-преобразования
Тогда поиск будет очень быстрым
в противном случае придётся перебирать весь Z-индекс, что iv_an_ru и пытался как я понимаю сказать

ИМХО , что бы попадать в интервал
нужно понимание глубины детализации.
То есть масштаб или возможные варианты выбора масштаба должны быть известны заранее.

Добавление нового масштаба потом вызовет критическую деградацию производительности.

По хорошему нужно строить хранение обьектов на радиальных координатах от центра Земли,
но мне неизвестны ГИС библиотеки, которые таким образом хранят первичные данные.
тогда любой масштаб будет достаточно просто пересчитываться через синус угла и преобразование
мебиуса.

nikichalekealon(Ruslan)пропущено...


тут проблема в том, что желательно что бы все точки "поискового прямоугольника" выпадали на один интервал Z-преобразования
Тогда поиск будет очень быстрым
в противном случае придётся перебирать весь Z-индекс, что iv_an_ru и пытался как я понимаю сказать

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

Прошу прощения но другой простой аналогии я не смог быстро придумать.

Помнишь мультик Винипух в госятх у кролика ?

maytonnikichale, эта картинка - обладает полнотой информации для Quad-Trees. Но для Z-curve на ней
недостаточно информации. В частности порядок связей не учтен.

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

в 16 раз , Карл !!!!
:)

nikichaleд0k,

В чем проблема, если нужно пробежать 4е маленьких интервала в индексе. Размер интервалов зависит от размера прямоугольника поиска. И точек в них будет на намного больше, чем реально содержит прямоугольник поиска.

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

nikichaleд0kпропущено...


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

в 16 раз , Карл !!!!
:)

Боитесь считать лишнего - покройте не 4мя квадратами, а 9 или 16. Кроме того, если говорить о ГИС, то информация вблизи уже запрошенной очень даже может понадобиться в последствии - типа user двигает карту на экране...

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

Это ваше право , но я тут что бы пообсуждать фунтаментальные возможности ,
и получить направления развития мысли,
а не подпорки и костыли в проекте работающем по принципу go-go.

Извините, мне экстенсивные решения не интересно обсуждать.

maytonд0kпропущено...


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

в 16 раз , Карл !!!!
:)
Ну почему-же. Если мы вернемся к стоимости дисковых операций и вспомним что
иногда проще читать 1 длинный IOPS, чем 2 коротких то возможно не все так
и печально, Карл.

Надо только придумать как сделать UNION.

Шо тут думать, тут прыгать надо :)

man 7 aio lio_listio(3) Enqueue multiple I/O requests using a single function
call.

maytonд0kЭто ваше право , но я тут что бы пообсуждать фунтаментальные возможности ,
и получить направления развития мысли, а не подпорки и костыли в проекте работающем по принципу go-go.
Извините, мне экстенсивные решения не интересно обсуждать.
Док. Извини но мы всю жизнь тут решаем фундаментально-практические 50:50 вопросы.
Такова жизсть иначе сиделы-бы в форуме математиков.

Z-курва есть некое переосмысление последовательного доступа к многомерным данным и от размера
страницы, сектора, экстента в базе мы никуда не денемся.

Собственно за это мы и получаем деньги. За умение совокуплять математику и эти странные
limitations железа и уже имеющегося ПО.

Была бы конкретная постановка задачи , можно было бы ее обсуждать.
1 , 5, 1024 масштабных сеток , поличическая карта мира итд итп....

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

Это общая дискуссия , а не конкретная , поэтому я стараюсь , что бы
найденные в ней решения покрывали максимальную масштабируемость ГИС системы.

maytonд0k, кстати залогонься. Я тебе тогда мыло смогу отправлять.

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

пиши на
doxtap вухо гмило.ком

nikichaleд0k,

Насчет масштабных сеток что-то не понял. Есть таблица с графикой, есть границы максимальные. Вводим дискретизацию, например, 2^28 дискретов (28 уровней). Если это география, то в дискрете меньше метра. Для точек в таблице строим индекс по Z-порядку 28+28 - ключ влезает в Int64. Для поиска точек в прямоугольнике от 1м и больше используем этот индекс. Причем на лицо явная избыточность - маловероятно, что на 1м будет находиться много географических объектов. Где же тут нарушена универсальность? Если же речь о чертеже микросхемы и нужно искать в миллиметровых интервалах - положите эти данные в другую таблицу отдельно от географии.

согласен , простота сестра таланта, что то в этом есть.
Но и вопросы есть

Почему 28 ?
можете обьяснить лоигическую и физическую суть этого магического числа ?

Почему не 38 ? ( если я не ошибся , площадь Земли в квадратных метрах 38 разнядное
двоичное число )

И какой по вашему лучше выбрать площадь одного Z квадрата ?

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

maytonд0kу вас есть улица длиной 5 км и шириной 30 м.
Как должно быть построено индексное хранение , что бы тыцнув
мышей в карту в любом месте улицы , получить ее название и координаты

дОК я тебя умоляю. Ну никто не ответит на твой вопрос.

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

maytonд0kу вас есть улица длиной 5 км и шириной 30 м.
Как должно быть построено индексное хранение , что бы тыцнув
мышей в карту в любом месте улицы , получить ее название и координаты

дОК я тебя умоляю. Ну никто не ответит на твой вопрос.

Это кстате задача по сабжу, только мы ищем не точки ,
а анлогичные объекты ( улицы и перекрестки) .



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