-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Векторная карта местности, как реализовать?
- Автор темы DpoHro
- Дата начала
DpoHro
Новичок
мда...
Уважаемый, я не просил шутить...
-~{}~ 04.07.06 22:42:
Предвкушая следующий пост в духе "какой вопрос, такой ответ" поясню...
Так как имею не особенно большой опыт в создании порталов хочу знать:
1. Как сохранить в одной записи (может даже в 1 ячейке) в базе массив точек одной линии?
2. Разумно ли вообще использовать БД для хранения карты, может лучше XML?
Вопросы связанные с самим принципом формирования электронных карт меня не интересуют, так как осведомлен в этом вопросе..
-~{}~ 04.07.06 22:46:
Ну и естесственно советы от людей которые решали подобную задачу
Уважаемый, я не просил шутить...
-~{}~ 04.07.06 22:42:
Предвкушая следующий пост в духе "какой вопрос, такой ответ" поясню...
Так как имею не особенно большой опыт в создании порталов хочу знать:
1. Как сохранить в одной записи (может даже в 1 ячейке) в базе массив точек одной линии?
2. Разумно ли вообще использовать БД для хранения карты, может лучше XML?
Вопросы связанные с самим принципом формирования электронных карт меня не интересуют, так как осведомлен в этом вопросе..
-~{}~ 04.07.06 22:46:
Ну и естесственно советы от людей которые решали подобную задачу
Stierus
Новичок
Если тебе не обязательно, что бы всё это как-то относилось к сети ( можно иметь только локальный доступ ) - то я посоветовал бы тебе обратить внимание на программу maphinfo ... если же тебе нужно карту привязать к web - напиши тут, я как домой подойду - скину статейку ... но одним php и бд ты явно всёравно не отделаешься.
Если тебя интересует район г. Москвы - логичнее воспользоваться Яндексовской картой ... тем более что они подробно описали api, всё удобно и просто ... вобщем подробнее суть проблемы опиши
Если тебя интересует район г. Москвы - логичнее воспользоваться Яндексовской картой ... тем более что они подробно описали api, всё удобно и просто ... вобщем подробнее суть проблемы опиши
DpoHro
Новичок
Суть:
Мастачу сайт. Портал. Региональный ресурс "оз. Селигер" кто слышал сразу ассоциация "туризм".
Карту хочу сделать одного района Тверской области, ну может некоторые соседние затронет, озеро большое.
Много турбаз, много стоянок для туристов...
Хотелось бы проложить маршруты, география тоже не помешала бы ...
Вобщем то хотелось бы обойтись одним PHP/mySQL так как ресурс не настолько коммерческий, чтобы использовать дорогие решения...
Для меня единственный вопрос - оптимизация по скорости, думаю если подскажете как засунуть в поле массив целочисленных пар (x,y) произвольной длины, то дело сдвинется
Мастачу сайт. Портал. Региональный ресурс "оз. Селигер" кто слышал сразу ассоциация "туризм".
Карту хочу сделать одного района Тверской области, ну может некоторые соседние затронет, озеро большое.
Много турбаз, много стоянок для туристов...
Хотелось бы проложить маршруты, география тоже не помешала бы ...
Вобщем то хотелось бы обойтись одним PHP/mySQL так как ресурс не настолько коммерческий, чтобы использовать дорогие решения...
Для меня единственный вопрос - оптимизация по скорости, думаю если подскажете как засунуть в поле массив целочисленных пар (x,y) произвольной длины, то дело сдвинется
bgm
Как я понимаю, задача работы с картографической информацией (хранение участков, выделение маршрутов и т.д.) разбивается на две:
1) Хранение ориентированного графа в базе данных;
2) Конструирование конкретных выборок.
Оба этих вопроса достаточно подробно описаны в интернете. Но надо понимать, что реляционные БД не оптимальны для хранения графов и работы с ними. Ещё стоит обратить внимание на матрицы смежности (особенно для хранения маршрутов).
Если же вернуться к сути вопроса о хранении массива, то правильнее будет его хранить не в одном поле, а использовать дополнительную таблицу вида: | id | order | x | y |, где поле order используется для определения порядка элементов массива.
1) Хранение ориентированного графа в базе данных;
2) Конструирование конкретных выборок.
Оба этих вопроса достаточно подробно описаны в интернете. Но надо понимать, что реляционные БД не оптимальны для хранения графов и работы с ними. Ещё стоит обратить внимание на матрицы смежности (особенно для хранения маршрутов).
Если же вернуться к сути вопроса о хранении массива, то правильнее будет его хранить не в одном поле, а использовать дополнительную таблицу вида: | id | order | x | y |, где поле order используется для определения порядка элементов массива.
DpoHro
Новичок
Wicked, не знаю не знаю, может и подойдет, буду глядеть...
Я понимаю, конечно, что идея хранить данные в БД не очень хорошая идея, так как хрен знает сколько там получится в общей сложности данных, справится ли на оптимальной скорости мускул да и вообще удастся ли написать достаточно быстро работающий алгоритм...
bgm, order я так понимаю ID линии? Мне кажется точек будет очень много... Почему я и зотел хранить линии массивом в одной записи, и тут не знаешь что лучше отдать время на выборку из таблицы линии, или же на распаковку массива....
Я уже начинаю подумывать просто обвести карту (я уже сделал обводилку на Delphi) сделать несколько jpeg-ов для разных масштабах и выдирать их кусками, ну и отдельно данные по маршрутам и прочим вещам хранить, хотя идея такая мне не нравится
Я понимаю, конечно, что идея хранить данные в БД не очень хорошая идея, так как хрен знает сколько там получится в общей сложности данных, справится ли на оптимальной скорости мускул да и вообще удастся ли написать достаточно быстро работающий алгоритм...
bgm, order я так понимаю ID линии? Мне кажется точек будет очень много... Почему я и зотел хранить линии массивом в одной записи, и тут не знаешь что лучше отдать время на выборку из таблицы линии, или же на распаковку массива....
Я уже начинаю подумывать просто обвести карту (я уже сделал обводилку на Delphi) сделать несколько jpeg-ов для разных масштабах и выдирать их кусками, ну и отдельно данные по маршрутам и прочим вещам хранить, хотя идея такая мне не нравится
whirlwind
TDD infected, paranoid
>>>как хранить данные?
>>в виде векторов
>Уважаемый, я не просил шутить...
Не, вообще то я не шутил, чесслово. Что такое вектор - это {x,y,z} ну или на декартовой {x,y}. Даже такой неуч как я, знает по крайней мере 2 способа рпредставления линии с помощью пары {x,y}. Если учили в школе математику, то должны знать уравнение прямой. Этого практически достаточно для того, что бы избежать хранения
> в одной записи (может даже в 1 ячейке) в базе массив точек одной линии?
>>в виде векторов
>Уважаемый, я не просил шутить...
Не, вообще то я не шутил, чесслово. Что такое вектор - это {x,y,z} ну или на декартовой {x,y}. Даже такой неуч как я, знает по крайней мере 2 способа рпредставления линии с помощью пары {x,y}. Если учили в школе математику, то должны знать уравнение прямой. Этого практически достаточно для того, что бы избежать хранения
> в одной записи (может даже в 1 ячейке) в базе массив точек одной линии?
DpoHro
Новичок
При помощи одной пары (х,у) и только нельзя представить линию, а уравнение прямой строится по 2 точкам, либо по 1 точке и вектору, либо по 1 точке и параллельной (перпендикулярной) прямой (вобщем способов то гораздо больше 2 это точно) но никак не по одной паре ху, уважаемый...
Ничего умного и сверхнового Вы не сказали, ИМХО что хранить 2 точки для (не ломаной) 1 линии, что хранить точку и вектор - одно и то же...
Но! В предложенном Вами методе (если я правильно понял) будет происходить дублирование данных при хранении ломаных полилиний, у которых одна линия является продолжением другой. То есть количество точек при вашем методе будет n*2 а при хранении массива точек полилинии n+1. Детский сад ИМХО, толкуем на тему уроков математики 5-го класса
Ничего умного и сверхнового Вы не сказали, ИМХО что хранить 2 точки для (не ломаной) 1 линии, что хранить точку и вектор - одно и то же...
Но! В предложенном Вами методе (если я правильно понял) будет происходить дублирование данных при хранении ломаных полилиний, у которых одна линия является продолжением другой. То есть количество точек при вашем методе будет n*2 а при хранении массива точек полилинии n+1. Детский сад ИМХО, толкуем на тему уроков математики 5-го класса
McSimm
Новичок
Можно ведь вектор хранить не в одной записи
Если все векторы единообразны и суть ломаные, то особых сложностей и нет, в записи номер вектора и одну точку (ее номер и координаты)
Stierus
Не очень разумное решение. Это если мягко
Иногда можно и удобно структуры хранить и в виде строки, но для этого есть более удобный механизм.
bgm
Нет, это порядковый номер точки в некоторой последовательности.
Заметь - последовательности могут быть нескольких типов:
- замкнутая фигура (элемент карты или маршрут);
- некая ломаная линия (маршрут, река, дорога и т.д.);
- точка (пункт).
Т.е. будут четыре таблицы:
- таблица типов элементов карты;
- таблица географических точек на карте;
- таблица элементов карты;
- таблица, в которой хранится последовательность географических точек для каждого элемента.
Из моей практики - работать очень удобно.