Показать полную графическую версию : [решено] Оптимальное решение для привязки координат к географическим объектам на MS SQL Server
Это как-то связано с упомянутыми полигонами? »
Изначально, когда было разделение на небольшие возможные регионы (лишь несколько районов московской области), использовалась таблица, в столбце которой хранились полигоны этих районов и использовался тип данных - geometry. Далее осуществлялась проверка вхождения точки из таблицы измерения в полигон. таким образом точки соотносились с географическими областями.
Откуда будут браться координаты реальных географических объектов? Какая-то база? »
Планируется, сделать геокодирование по всем точкам при помощи яндекс-карт, google-maps, 2gis, mapinfo. Каким именно сервисом пользоваться еще не знаю. Но выбор будет среди них. Другого под рукой ничего нет.
lxa85, некоторые сами «рисуют» карты: Waze: нам по пути, или История маленького, но очень гордого стартапа (http://www.computerra.ru/69604/waze/).
Изначально, когда было разделение на небольшие возможные регионы (лишь несколько районов московской области), использовалась таблица, в столбце которой хранились полигоны этих районов »
Ну, таково было и моё видение. Вы от этого решили уйти? Почему?
и использовался тип данных - geometry. »
Где можно почитать — что это за тип данных в Microsoft SQL Server?
Где можно почитать — что это за тип данных в Microsoft SQL Server? »
Когда я разбирался, читал все на MSDN (http://msdn.microsoft.com/ru-ru/library/bb933973%28v=sql.100%29.aspx).
Вы от этого решили уйти? Почему? »
Проверка вхождения точки в полигон, созданный типом geometry Sql Server занимает довольно долгое время. Притом, что было всего порядка 25-30 таких полигонов. С учетом, того, что сейчас необходимы полигоны не только такого количества групп, а намного больше, я думаю, время обработки намного увеличится. Кроме того, для создания этих полигонов, необходимо знать краевые точки всех этих географических объектов. Что так же добавляет трудности в создании таблицы с географическими объектами.
Когда я разбирался, читал все на MSDN. »
Спасибо, ясно.
LilLoco, почему бы не делать привязку к нижнеуровневому объекту не в момент выборки, а в момент добавления строки с измерением в таблицу?
а в момент добавления строки с измерением в таблицу? »
Процесс добавления - закрытый. Добавление происходит при помощи ПО, поставляемого вместе с измерительным комплексом. Получается, что при добавлении мы никак не можем повлиять на структуры таблиц.
Плюс, могу сказать, что добавление производится не всегда в одни и те же базы данных. Поэтому, например, использование триггеров, срабатывающих на добавление записей, является невозможным.
привязку к нижнеуровневому объекту »
В любом случае необходим источник этих объектов. И вот в каком формате целесообразнее хранить эти объекты, на данный момент, является для меня все еще загадкой.
Процесс добавления - закрытый. »
Ясно. Я думал, всё сугубо Ваше.
А как насчёт делать привязку в момент пересчёта? Есть же технологические перерывы какие-нибудь?
В любом случае необходим источник этих объектов. И вот в каком формате целесообразнее хранить эти объекты, на данный момент, является для меня все еще загадкой. »
Например: Измерения[Id Измерения, Координаты, Измерения, Принадлежность] ⇚ один ко многим → Объекты[Id, Наименование, Подчинение (ссылка на Id в этой же самой таблице)] ← один ко многим ⇛ Полигоны[Id, Id Объекта, координата точки полигона, порядковый номер точки].
Схема базы данных:
http://img705.imageshack.us/img705/5712/image00120130603162132.png
(вторая таблица «Объекты» на схеме — фиктивная, только для того, чтобы показать связь, ссылку с одной записи таблицы на другую запись той же таблицы).
Так вот, в этой схеме поле «Принадлежность» (к объекту нижнего уровня) можно заполнять позже.
Пожалуй, таблицу Полигоны также стоит разбить на две подтаблицы: собственно Объект[Id, Наименование (что-то я забыл про это на схеме), Подчинение] и ТочкиПолигона[Id точки, координата точки полигона, порядковый номер точки, Id Полигона].
А как насчёт делать привязку в момент пересчёта? Есть же технологические перерывы какие-нибудь? »
Да такой вариант вполне уместен. Перерывов предостаточно, в разумной степени естественно.
Iska, Спасибо большое за разъяснения. Буду пробовать.
Спасибо всем за помощь в этом, нелегком для меня, деле.
Тему пока отмечу решенной
LilLoco, я сейчас ещё подумал (да, бывает и такое — я думаю ;)) — таблицу Полигоны, что на схеме, надо обязательно разбить на две таблицы: один объект может состоять из нескольких полигонов, тогда как раз логично держать отдельно сами полигоны (как сущность) и отдельно, так же — как сущность, точки конкретного полигона.
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.
Available in ZeroNet 1osznRoVratMCN3bFoFpR2pSV5c9z6sTC