Вообще-то кучка ссылок приведена по ссылке в 5 посте.
Гарантий, что “точно так же”, понятное дело, никаких, но ведь вопрос не в том, чтобы “были шашечки”. Вполне вероятно, что для ваших конкретных нужд избранный вами способ индексации окажется эффективнее принятого в OSM API.
Nominatim строит индекс именно по геометрическому попаданию в.
Собственно, у него других вариантов и нет, все остальные виды “зависимостей” слишком утопичны
Вообще “все остальные способы” заключаются в построении ссылок и применяются в форматах основаных на GDF и во всех форматах основаных на MapInfo и в польском формате (это форматы исходных данных для карты, не путать с форматами конечными, такими как у гармина навитела томтома). Строить сложнее так как надо расставлять ссылки, но конечному пользователю ЗНАЧИТЕЛЬНО проще это обрабатывать. Так как ненадо производить большие вычислительные действия связанные с поиском попадания части линии в невыпуклый многоугольник с дырками или состоящий из островков (одна и та же улица может рпоходить через несколько админ едениц). Конфигурация админ едениц бывает довольно замысловатая (особено в англии).
OSM это первый формат который я увидел с админ деление сделаным не на ссылках (на прямых ссылках когда линия ссылается на арену или на обратных когда етсь отношение между аренами и линиями)
Пространственный индекс применяется не для поиска по адресу, а для быстрой выборки по координатам. Причем применяется совместно с пространственной сортировкой данных (чтобы данные лежащие рядом на карте лежали рядом в файле). Для поиска по адресу пространственный индекс не нужен. надо построить сециальную структуру ориентированную на поиск по именам. Можно применить много способов все зависит от того как буде работать поиск (пок каому принципу). Поиск попадания в арену пространственным индексом не обработаеш так как у арены сложная форма, всеравно придется обрабатывать все координаты арены и линий которые попали в МБР арены. Пространственный индекс уменьшит количество перебираемых линий но строится все будет всеровно тяжко. Так как в общем случае одну и туже линию придется сравнить с кучей арен МБР которыйх пересекается. Поэтому производители коммерческих карт облегчают жизнь пользователям и сразу создают ссылочную структуру позволяющую более менее легко строить различные индексы для различных способов поиска по адресу.
Несколько месяцев назад я предлагал создать древовидную адресную структуру на релейшенах. Но идею, как всегда, завалили. Хотя такая структура решала бы все вопросы адресации минимальной кровью.
Всё правильно. Единственная проблема - никто не будет эти ссылки ставить, хотя бы потому что рисующему конечный пользователь сильно по барабану.
А если кто и возьмётся, то порушатся эти ссылки очень-очень скоро.
Все правильно, только отношение, хотя и наиболее подходящий из всех существующих в настоящий момент элементов, но по-хорошему нужно ввести дополнительную сущность - объект, который и будет состоять из узлов, путей и отношений.
Но толку от этих объектов тоже будет чуть, пока POI и пути можно будет обрабатывать отдельно от объектов.
Что же касается иерархии объектов, то просто напросто нужен софт, который НЕ ПОЗВОЛИТ разместить объект вне существующей структуры. Но для этого сама структура должна быть тщательно продумана, чего, увы, в настоящее время не наблюдается.
Но и этого на самом деле мало. Достаточно будет лишь если пользователи, т.е. те, кто рисует карту, примут эту структуру и этот софт.