Что лучший способ состоит в том, чтобы считать, представить и представить данные карты?
Что-то не так с вашим примером: вы присоединяетесь к сервисному тегу
Systemunittransactions AS Sct
LEFT JOIN Systemunittransactions AS Sct1 ON Sct1.Servicetag = Sct.Servicetag
, но после этого вы фильтруете по двум разным тегам в каждой таблице:
Sct.Servicetag = 'IDXXX12' AND Sct1.Servicetag = 'IDXX12',
еще один Х, чем другой. Это объединение с этим фильтром никогда не будет работать. Предполагая, что в вопросе содержится ошибка пропущенной буквы, и приведенный вами пример таблицы, в котором не более одной строки с одной и той же парой идентификаторов, ищет запрос:
[112 ]11 ответов
Во-первых, я рекомендую использовать файлы ТИГРА 2008 года.
Во-вторых, поскольку другие указывают там, много проектов там теперь, когда уже считанный в, интерпретируйте, преобразуйте и используйте данные. Создание Вашего собственного синтаксического анализатора для этих данных почти тривиально, тем не менее, таким образом, нет никакой причины пройти код другого проекта и попытку извлечь то, в чем Вы нуждаетесь, если Вы не планируете использование их проекта в целом.
Если Вы хотите начать с более низкого уровня
Парсинг
Создание Вашего собственного синтаксического анализатора ТИГРА (довольно легкий - просто DB линейных сегментов) и создание простого рендеринга к тому же (строки, полигоны, буквы/имена) также будут довольно легкими. Вы захотите посмотреть на различные типы проекции карты для фазы рендеринга. Наиболее часто используемый (и поэтому самый знакомый пользователям) Меркаторская проекция - это довольно просто и быстро. Вы могли бы хотеть играть с поддержкой других проекций.
Это обеспечит немного 'забавы' с точки зрения наблюдения, как спроектировать карту, и как инвертировать ту проекцию (скажите, что пользователь нажимает на карту, Вы хотите видеть lat/lon, который они нажали - требует инвертирования текущего уравнения проекции).
Рендеринг
Когда я разработал свой рендерер, я решил основывать свое окно на фиксированном размере (встроенное устройство), и фиксированное увеличение. Это означало, что я мог центрировать карту в lat/lon, и с центром pixel=center lat/lon при данном увеличении, и, учитывая меркаторскую проекцию я мог вычислить, какой пиксель представил каждый lat/lon, и наоборот.
Некоторые программы вместо этого позволяют окну варьироваться, и вместо того, чтобы использовать увеличение и фиксированную точку, они используют две фиксированных точки (часто левые верхние углы и правые нижние углы прямоугольника, определяющего окно). В этом случае это становится тривиальным для определения пикселя к передаче lat/lon - это - всего несколько вычислений интерполяции. Вращение и масштабирование делают эту функцию передачи немного более сложной, но не должны значительно быть так - это - все еще прямоугольное окно с интерполяцией, но углы окна не должны быть ни в какой конкретной ориентации относительно севера. Это добавляет несколько угловых случаев (можно вывернуть карту наизнанку и просмотреть ее, как будто из земли, например), но они не обременительны, и могут иметься дело с тем, поскольку Вы работаете над нею.
После того как у Вас есть lat/lon к пиксельной передаче, сделанные, представляющие строки и полигоны довольно просты за исключением нормальных графических проблем (таких как края строк или полигонов, накладывающихся неуместно, сглаживания, и т.д.). Но рендеринг основной ужасной карты, такой как сделанный многими рендерерами с открытым исходным кодом довольно прост.
Вы также сможете играть с расстоянием и большими круговыми вычислениями - например, хорошее эмпирическое правило - то, что каждая степень lat или lon на экватор составляет приблизительно 111.1 км - но каждый изменяется, поскольку Вы становитесь ближе к любому полюсу, в то время как другой продолжает оставаться на уровне 111.1 км.
Устройство хранения данных и структуры
То, как Вы храните и обращаетесь к данным, однако, зависит значительно от того, что Вы планируете на выполнении с ними. Много трудных проблем возникает, если Вы захотите использовать ту же структуру базы данных для демографии по сравнению с маршрутизацией - то структура основы определенных данных и индексация будут быстры для одной и замедлятся для другого.
Используя индексы и загрузку только соседние индексы работают на маленькую карту, представляющую проекты, но если Вам нужен маршрут по всей стране, Вам нужна другая структура. Некоторые реализации имеют базы данных 'наложения', которые только содержат главные дороги и маршруты снимков к наложению (или через несколько оверлейных программ - локальный, метро, графство, состояние, страна). Это приводит к быстрой, но иногда неэффективной маршрутизации.
Мозаичное размещение
Мозаичное размещение Вашей карты на самом деле не легко. При более низких увеличениях можно представить целую карту и сократить ее. При более высоких увеличениях Вы не можете представить все это сразу (из-за памяти/пространственных ограничений), таким образом, необходимо нарезать ее.
Вырезание строк на границах мозаик, таким образом, можно представить отдельные результаты мозаик в меньше, чем идеальных результатах - часто, что сделано, является строками, представляются вне границы мозаики (или, по крайней мере, данные конца строки сохранены, хотя представив остановки, после того как это находит, что упало с края) - это уменьшает ошибку, которая происходит при сходстве со строк, они не вполне соответствуют, когда они перемещаются через мозаики.
Вы будете видеть то, что я говорю о том, поскольку Вы работаете над этой проблемой.
Это не тривиально для нахождения данных, которые входят в данную мозаику также - строка может иметь оба конца вне данной мозаики, но переместиться через мозаику. Необходимо будет консультироваться с графическими книгами об этом (книга Michael Abrash является оригинальной ссылкой, в свободном доступе теперь в предыдущей ссылке). В то время как это говорит главным образом об играх, работе с окнами, отсечении, краях полигона, коллизии, и т.д. все применяются здесь.
Однако Вы могли бы хотеть играть в более высоком уровне.
После того как у Вас есть сделанное вышеупомянутое (или путем адаптации существующего проекта, или делая вышеупомянутое самих) можно хотеть играть с другими сценариями и алгоритмами.
Обратное геокодирование довольно легко. Вход lat/lon (или нажимают на карту) и получает ближайший адрес. Это учит Вас, как интерпретировать адреса вдоль линейных сегментов в данных ТИГРА.
Основное геокодирование является тяжелой проблемой. Запись синтаксического анализатора адреса является полезным и интересным проектом и затем преобразованием, что в lat/lon использование данных ТИГРА нетривиально, но большая забава. Начните простой и маленький путем требования точного имени и соответствия формата, и затем начните изучать 'как' соответствие и фонетическое соответствие. Существует большое исследование в этой области - смотрят на проекты поисковой системы для некоторой справки здесь.
Нахождение кратчайшего пути между двумя точками является нетривиальной проблемой. Существуют многие, много алгоритмов для того, чтобы сделать это, большинство которых запатентовано. Я рекомендую, чтобы, если Вы пробуете это движение легким алгоритмом Вашего собственного дизайна и затем проводите некоторое исследование и сравнили Ваш дизайн с состоянием. Это - большая забава, если Вы в теорию графов.
После пути и заблаговременно предоставления инструкций не так легко, как оно считает первый румянец. Учитывая ряд инструкций со связанным массивом lat/lon пар, 'следуйте' за маршрутом с помощью внешнего входа (GPS, или моделировал GPS), и разработайте алгоритм, который дает пользовательские инструкции, поскольку они приближаются к каждому реальному пересечению. Заметьте, что существует больше lat/lon пар, чем инструкции из-за изгибающихся дорог, и т.д., и необходимо будет обнаружить направление перемещения и т.д. Много угловых случаев, которые Вы не будете видеть, пока Вы не попытаетесь реализовать его.
Поиск интересного места. Этот интересен - необходимо найти, что текущее местоположение и все интересные места (не часть ТИГРА, делают собственное или получают другой источник) на определенном расстоянии (по прямой, или тяжелее - проезжать расстояние) источника. Этот интересен в этом, необходимо преобразовать базу данных POI в формат, который легко искать при этом обстоятельстве. Вы не можете не торопиться, чтобы пройти миллионы записей, сделать расчет расстояния (sqrt (x^2 + y^2)) и возвратить результаты. У Вас должны быть некоторый метод или алгоритм для сокращения объема данных сначала.
Коммивояжер. Маршрутизация с несколькими местами назначения. Просто более трудная версия регулярной маршрутизации.
Можно найти много ссылок на многие проекты и источники информации об этом предмете здесь.
Удача, и опубликуйте то, что Вы делаете, неважно, как элементарный или ужасный, таким образом, другие могут извлечь выгоду!
- Adam
SharpMap является.NET с открытым исходным кодом 2,0 отображающихся механизма для WinForms и ASP.NET. Это может обеспечить всю функциональность, в которой Вы нуждаетесь. Это имеет дело с наиболее распространенным вектором GIS и растровыми форматами данных включая файлы форм ESRI.
решение:
- геопространственный сервер как mapserver, геосервер, градус (открытый исходный код).
Они могут прочитать и вручить файлы форм (и много других вещей). Например, геосервер (при установке) данные подачи из американских файлов форм Бюро переписи ТИГРА как демонстрация
- картографическая библиотека JavaScript как openlayers (см. примеры в тексте ссылки
Существует много примеров в сети с помощью этого решения
для того, чтобы хранить данные тигра локально, я был бы, выбрал Postgresql с инструментами постстекла.
у них есть впечатляющий набор инструментов для Вас особенно, Геокодер Тигра предлагает хороший способ импортировать и использовать данные тигра.
необходимо будет смотреть на инструменты, которые взаимодействуют с постстеклом, скорее всего, своего рода mapserver
из http://postgis.refractions.net/documentation/:
Существует теперь несколько инструментов с открытым исходным кодом, которые работают с PostGIS. uDig проект работает над полной настольной средой чтения-записи, которая может работать с PostGIS непосредственно. Для интернет-отображения Миннесотский университет Mapserver может использовать PostGIS в качестве источника данных. Инструментарий GeoTools Java GIS сделал, чтобы PostGIS поддерживал, как делает веб-Сервер Функции GeoServer. ТРАВА поддерживает PostGIS как источник данных. Рабочий стол Java ПЕРЕХОДА средство просмотра GIS имеет простой плагин для чтения данных PostGIS и рабочего стола QGIS, сделал, чтобы хороший PostGIS поддерживал. Данные PostGIS могут быть экспортированы в несколько выводов форматы GIS, пользующиеся библиотекой C++ OGR и инструментами командной строки (и курса со связанным самосвалом Файла форм). И конечно любой язык, который может работать с PostgreSQL, может работать с PostGIS - список включает Perl, PHP, Python, TCL, C, C++, Java, C#, и т.д.
править: depite mapserver наличие слова СЕРВЕР на его имя, это будет применимо в настольной среде.
Забавный вопрос. Вот то, как я делаю это.
Я собираю любую геометрию, в которой я нуждаюсь в любых форматах, они входят. Я вытягивал данные из USGS, так, чтобы суммы к набору:
- Файлы SHP (файл форм ESRI техническое описание)
- Файлы DBF (Файл данных Xbase (*.dbf))
Я затем записал программу, которая "компилирует" те определения формы в форму, которая эффективна для рендеринга. Это означает делать любые проекции и преобразования формата данных, которые необходимы для эффективного отображения данных. Некоторые детали:
- Для 2D приложения можно использовать любую проекцию, которую Вы хотите: Проекции Карты.
- Для 3D Вы хотите преобразовать их широта/долготы в 3D координаты. Вот некоторая математика о том, как сделать это: преобразование от сферических координат до нормальных прямоугольных координат.
- Разбейте все примитивы в (2D/3D) дерево квадрантов/дерево октантов. Вершины в этом дереве содержат ссылки на всю геометрию, которая пересекает (выровненную осью) ограничительную рамку той вершины. (Это означает, что на часть геометрии можно сослаться несколько раз.)
- Геометрия затем разделяется на таблицу вершин и таблицу команд рисования. Это - идеальный формат для OpenGL. Команды могут быть даны через glDrawArrays использование буферов вершины (Буферные Объекты Вершины).
- Общий шаблон "посетитель" используется для обхода дерева квадрантов/дерева октантов. Обход включает тестирование, пересекает ли посетитель данные узлы дерева, пока с вершиной не встречаются. Посетители включают: рисунок, обнаружение коллизий и выбор. (Поскольку древовидные листы могут содержать дублирующиеся ссылки на геометрию, Уокер отмечает узлы, как посещаемые, и игнорирует их после этого. Эти метки должны быть сброшены или иначе обновлены прежде, чем сделать следующий обход.)
- Используя пространственную систему разделения (одно из деревьев) и эффективное рисунком представление крайне важно для достижения высокого framerates. Я нашел, что в этих типах приложений, Вы хотите свою частоту кадров максимально высоко 20 кадр/с как минимум. Не говоря уже о том, что большая производительность даст Вам много возможностей создать лучше выглядящую карту. (Шахта, совсем не красивая, но, доберется там однажды.)
- Пространственное разделение помогает выполнению рендеринга путем сокращения количества команд ничьей, отправленных на процессор. Однако там мог прибыть время, когда пользователь на самом деле хочет просмотреть весь набор данных (возможно, ареальное представление). В этом случае Вам нужна система управления уровня детализации. Так как мое приложение имеет дело с улицами, я уделяю первостепенное значение магистралям и более крупным дорогам. Мой код для прорисовки знает о том, сколько примитивов я могу потянуть, прежде чем мой framerate понижается. Примитивы также отсортированы по этому приоритету. Я тяну только первое
xобъекты, гдеxколичество примитивов, которые я могу потянуть в своем желаемом framerate.
Остальное - управление камерой и анимация любых данных, которые Вы хотите отобразить.
Вот некоторые примеры моей существующей реализации:
Изображение http://seabusmap.com/assets/Picture%205.png Изображение http://seabusmap.com/assets/Picture%207.png
Хотя Вы уже решили использовать данные ТИГРА, Вы могли бы интересоваться OSM (Открытая Карта города), потому что OSM имеет полный импорт данных ТИГРА в нем, обогащенный пользователем внес данные. Если Вы будете придерживаться формата ТИГРА, то Ваше приложение будет бесполезно международным пользователям с OSM, Вы получаете ТИГРА и все остальное сразу.
OSM является открытым проектом, показывающим совместно отредактированную карту свободного мира. Можно добраться, все эти данные также структурировали XML, или запрос для региона, или загрузите целый мир в большом файле.
Существуют некоторые рендереры карты для OSM, доступного на различных языках программирования, большинстве из них открытый исходный код, но все еще существует очень, чтобы быть сделанным.
Также существует доступная служба маршрутизации OSM. Это имеет веб-интерфейс и могло бы также быть queriable через веб-сервис API. Снова, это все не закончено. Пользователи могли определенно использовать настольное или мобильное приложение маршрутизации, созданное сверху этого.
Даже если Вы не решаете пойти с тем проектом, можно получить большое вдохновение от него. Просто взгляните на Wiki проекта и на источники различных проектов программного обеспечения, которые включены (Вы найдете ссылки на них в Wiki).
Вы могли также работать с визуальным наземным приложением и API отображения Microsoft или использовать API Google. Я всегда программировал коммерчески с продуктами ESRI и не играл с открытым API так очень.
Кроме того, Вы могли бы хотеть посмотреть на Производителя! и Средство поиска! Они - относительно новые программы, но я думаю, что они свободны. Мог бы быть ограничен при встраивании данных. Производитель может быть найден здесь.
Проблема состоит в том, что пространственная обработка является довольно новой в не коммерческом масштабе.
Одно упрощение по Меркаторской или другой проекции должно принять постоянный коэффициент преобразования для широты и долготы. Умножьте степени широты на 69,172 мили; для долготы выберите среднюю широту своей области карты и умножьтесь (с 180 долготами) косинусом (middle_latitude) *69.172. После того как Вы преобразовали в мили, можно использовать другой набор преобразований для получения до координат экрана.
Это - то, что работало на меня назад в 1979.
Если Вы не возражаете платить за решение, Безопасное программное обеспечение производит продукт под названием FME. Этот инструмент поможет Вам перевести данные от любого формата до примерно любого другого. Включая KML Формат Google Earth или рендеринг это как JPEG (или серия JPEGs). После преобразования данных можно встроить землю Google в приложение с помощью их API или просто отобразить мозаичные изображения.
Как сторона не FME является очень мощной платформой поэтому при выполнении переводов, можно добавить или удалить части данных, в которых Вы не обязательно нуждаетесь. Источники слияния, если у Вас есть больше чем один. Преобразуйте координаты (я не помню что точно использование Google Earth). Хранилище копирует в базе данных. Но серьезно если Ваше согласное для выхода из оболочки нескольких маркеров необходимо изучить это.
Можно также создать флаги (во многом как в демонстрационной карте), которые содержат местоположение (куда поместить ее), и другие данные/комментарии о местоположении. Эти флаги прибывают во многие формы и размеры.
То, когда я дал, это отвечает на вопрос, было маркировано
"Каков был бы лучший способ представить Файл форм (данные карты) с ломаными линиями в .NET?"
Теперь это - другой вопрос, но я оставляю свой ответ на исходный вопрос.
Я записал версию .NET, которая могла потянуть векторные данные (такие как геометрия из shp файла) использование плоскости GDI + в c#. Это было довольно забавно.
Причина состояла в том, что мы должны были обработать различные версии конфигураций и атрибутов с большой дополнительной информацией, таким образом, мы не могли использовать коммерческий компонент карты или с открытым исходным кодом.
Главное при выполнении этого, устанавливают область просмотра и переводят/преобразовывают координаты WGIS84 в низкокачественное и GDI + x, y координаты и ожидают с проекцией, если даже необходимо повторно спроектировать вообще.
Одно решение состоит в том, чтобы использовать MapXtreme. У них есть API для Java и C#. API может загрузить эти файлы и представить их.
Для Java:
Для.NET:
Я использовал это решение в Настольном приложении, и оно работало хорошо. Это предлагает намного больше ту единственную информацию о рендеринге.
Теперь выполнение этого с нуля могло занять долгое время. У них действительно есть пробная версия, которую можно загрузить. Я думаю, что это просто печатает "MAPXTREME" по карте как водяной знак, но это абсолютно применимо иначе