Он вернет расширенную информацию о том где лежит кастелнау (город, графство и еще много чего). Имея файл ОСМ англии я несмог получить то же самое если икаьт по файлу “руками” через текстовый вьювер.
В OSM файле лежат элементы трех типов: точки, линии и “отношения”.
Координаты есть только у точек. У линий есть ссылки на точки, а у “отношений” - ссылки как на точки, так и на линии.
Обычно сложные объекты представляются “отношениями”.
Собственно, нужно просто собрать информацию по ссылкам из разных частей одного файла.
Ds: Если есть файл и по нему нужно восстановить один объект, дешевле делать это без индекса. Индекс нужен, когда нужно максимально быстро обрабатывать множественные запросы. В принципе наличие индекса сокращает время запроса на порядки, но и построение самого индекса во много раз дольше получения данных по одному объекту без использования индекса.
Дело не в индексе. Я не спрашиваю о конкретном механизме поиска у меня вопрос по МОДЕЛИ ДАННЫХ в ОСМ. Проблема в том что по ссылкам и отношениям не получается собрать нужную информацию, так как нет отношений в которых бы участвовали те элементы которые мне нужны. Тобиш все по отдельности там етсь и находятся. Но нет отношений которые бы говорили чо они связаны межлу собой. Например есть Richmond и есть Castelnau но нет ни одного отношения которое бы говорило что Castelnau лежит в Richmond. is_in у кастелнау то же не заполнен (как и у многих других улиц). Вообще судя по данным Кастелнау сама по себе и нигде не лежит, так как никто на нее не ссылается. НО ЧТО ИНТЕРЕСНО ОНЛАЙН ПОИСК ТО ЧТО МНЕ НАДО КАК ТОДЕЛАЕТ. Я думал может у них есть еще како то отдельный файл с дополнителной информацией.
Причем такая рпоблема не только в англии. То же самое и в России. Если искать по файлу то неуается установить связь между улицами и районами где они лежат. ТАк ак у многих не заполнен is_in и нет отношений между улицами и районами. Но чертов онлайн АПИ как то находит всю информацию
Мне надо узнать в каком районе города(если етсь)/городе/округе лежит улица. Например для улицы Типанова мне надо получить что она лежит в Московский район/Санкт-Петербург
По координатам попадание что ли смотреть? По ссылкам то что мне нужно никуда не входит. По координатам это конечно мощщно. Представляю сколькоон будет лопатить всю англию.
Совершенно верное замечание.
Это недостаток существующего формата.
Насколько я знаю, первоначально OSM оперировал лишь сущностями двух типов: узел и путь, но вскоре выяснилось, что этого совершенно недостаточно, после чего были введены отношения, но значительная часть софта либо вообще не умеет с ними работать, либо поддерживает весьма ограничено. А по-хорошему требуется две вещи:
Ввести дополнительную сущность более высокого уровня - объект.
Добиться того, чтобы все стальные сущности (узел, путь, отношение) рассматривались не как самостоятельные, а лишь как “кирпичики” для построения объектов. И, соответственно, не могли использоваться рендерами или конвертерами помимо объектов в которые они входят.
Сейчас же информация разбросана по разным частям файла и зачастую не связана между собой.
А API, насколько я понимаю, физически работает не с файлом, а с БД, которая сама индексирует данные, что позволяет сократить время поиска.
А тут надо оценивать баланс времени. В целом, справедливо:
время построения индекса >> время единичного поиска без индекса >> время единичного поиска при наличии индекса
Поэтому следует оценить количество запросов и, и исходя из него, сделать вывод о том, целесообразна ли индексация для решения конкретной задачи.
Вопрос в том как построить отношения для БД аналогичной той что использует АПИ. Понятно что напрямую с XML никто не работает. Только вот как нарыть отношения чтобы сделать такие же связ как в их БД пока не нашел. Пока единственный вариант походу это строить их геометрическим путем через границы областей и попадание вэев в эти области Я думал может есть еще какой способ более человечный.
В том что в ИСХОДНЫХ данные ненайти нужныз связей, СЛЕДОВАТЕЛЬНО Я МОГУ ХОТЬ ОБЗАЛИТЬСЯ В РАЗНЫЕ БАЗЫ но связи не появятся. А делать связи через геометрический поиск это уже всеравно через базу или самому руками, дело то не в этом а в поиске наиболее оптимального варианта построения связей. При этои неважно в MSSQL mysql еще каком SQL это все будет.
