Каков наилучший способ чтения, представления и отображения картографических данных?

Ответ 1

Во-первых, я рекомендую использовать 2008 TIGER файлы.

Во-вторых, как указывают другие, сейчас есть много проектов, которые уже читают, интерпретируют, конвертируют и используют данные. Построение собственного анализатора для этих данных почти тривиально, поэтому нет причин переходить через другой код проекта и пытаться извлечь то, что вам нужно, если вы не планируете использовать их проект в целом.

Если вы хотите начать с нижнего уровня

Синтаксический

Построение собственного анализатора TIGER (достаточно просто - всего лишь DB линейных сегментов), и создание простого рендеринга поверх этого (строки, многоугольники, буквы/имена) также будет довольно простым. Вы хотите посмотреть на различные типы проекций карты для фазы визуализации. Наиболее часто используемым (и, следовательно, самым знакомым для пользователей) является проекция Меркатора - это довольно просто и быстро. Вы можете играть с поддержкой других прогнозов.

Это даст немного "удовольствия" с точки зрения того, как проектировать карту и как отменить эту проекцию (например, пользователь нажимает на карту, вы хотите видеть, что lat/lon они нажали - требуется реверсирование текущее проекционное уравнение).

Rendering

Когда я разработал свой рендерер, я решил основать свое окно на фиксированном размере (встроенное устройство) и фиксированное увеличение. Это означало, что я мог бы центрировать карту на лат /lon, а с центром pixel = center lat/lon при данном увеличении, и, учитывая проекцию меркатора, я мог бы вычислить, какой пиксель представлял каждый lat/lon, и наоборот.

Некоторые программы вместо этого позволяют изменять окно, и вместо использования увеличения и фиксированной точки они используют две неподвижные точки (часто верхние левые и нижние правые углы прямоугольника, определяющие окно). В этом случае становится тривиальным определять передачу пикселя в lat/lon - это всего лишь несколько расчетов интерполяции. Вращение и масштабирование делают эту передаточную функцию немного более сложной, но не должны быть значительно такими - это еще прямоугольное окно с интерполяцией, но углы окна не обязательно должны быть в какой-либо конкретной ориентации относительно северного. Это добавляет несколько угловых случаев (вы можете повернуть карту наизнанку и просмотреть ее, как если бы изнутри земли, например), но они не обременительны и могут быть рассмотрены, когда вы работаете над ней.

После того, как вы выполнили передачу с использованием lat/lon to pixel, линии рендеринга и многоугольники довольно просты, за исключением обычных проблем с графикой (например, края линий или многоугольников, перекрывающихся ненадлежащим образом, сглаживание и т.д.). Но предоставление базовой уродливой карты, например, сделанной многими рендерингами с открытым исходным кодом, довольно просто.

Вы также сможете играть с расчетами расстояний и больших кругов - например, хорошее эмпирическое правило состоит в том, что каждая степень lat или lon на экваторе составляет приблизительно 111,1KM, но каждый изменяется по мере приближения к полюс, в то время как другой продолжает оставаться на уровне 111,1 км.

Хранение и структуры

Как вы храните и ссылаетесь на данные, однако, во многом зависит от того, что вы планируете делать с ним. Возникает множество трудных проблем, если вы хотите использовать одну и ту же структуру базы данных для демографии и маршрутизации - данная структура базы данных и индексирование будут быстрыми для одного и медленными для другого.

Использование zipcodes и загрузка только близлежащих zipcodes работает для небольших проектов рендеринга карт, но если вам нужен маршрут по всей стране, вам нужна другая структура. В некоторых реализациях есть "оверлейные" базы данных, которые содержат только основные дороги и привязки маршрутов к оверлею (или через множественные оверлеи - локальные, метро, ​​уезд, штат, страну). Это приводит к быстрой, но иногда неэффективной маршрутизации.

Черепица

Наложение вашей карты на самом деле непросто. При меньших увеличениях вы можете отобразить всю карту и разрезать ее. При более высоких увеличениях вы не можете отобразить все сразу (из-за ограничений памяти/пространства), поэтому вам нужно нарезать его.

Режущие линии на границах плиток, чтобы вы могли визуализировать отдельные плитки, достигали менее совершенных результатов - часто делается то, что линии выводятся за пределы плитки (или, по крайней мере, данные конца строки сохраняются, хотя рендеринг останавливается, как только он находит, что он упал с края) - это уменьшает ошибку, которая возникает с линиями, выглядящими так, как будто они не совсем совпадают, когда они перемещаются по фрагментам.

Вы увидите, о чем я говорю, когда вы работаете над этой проблемой.

Нет ничего сложного в том, чтобы найти данные, которые попадают в данную плиту, - линия может иметь оба конца за пределами данной плитки, но перемещаться по плиткам. Вам нужно будет проконсультироваться с графическими книгами об этом (Майкл Абраш - это основная ссылка, свободно доступная по предыдущей ссылке). Хотя речь идет в основном об играх, здесь применяются окна, обрезка, полигоны, столкновение и т.д.

Однако вы можете играть на более высоком уровне.

Как только вы сделаете это (либо путем адаптации существующего проекта, либо сделайте это самостоятельно), вы можете играть с другими сценариями и алгоритмами.

Обратное геокодирование достаточно просто. Введите lat/lon (или щелкните по карте) и получите ближайший адрес. Это объясняет, как интерпретировать адреса по сегментам линии в данных TIGER.

Основное геокодирование - сложная проблема. Написание парсера адресов - полезный и интересный проект, а затем преобразование его в lat/lon с использованием данных TIGER является нетривиальным, но очень весело, Начните простые и маленькие, требуя точного совпадения имени и формата, а затем начните искать "подходящее" соответствие и фонетическое соответствие. Там много исследований в этой области - посмотрите на поисковые проекты для некоторой помощи здесь.

Поиск кратчайшего пути между двумя точками - нетривиальная проблема. Для этого существует множество алгоритмов, большинство из которых запатентованы. Я рекомендую, если вы попробуете это пойти с легким алгоритмом вашего собственного дизайна, а затем выполните некоторые исследования и сравните свой дизайн с уровнем техники. Это очень весело, если вы в теории графов.

По пути и упреждающим инструкциям не так просто, как при первом румянце. Учитывая набор инструкций со связанным массивом пар lat/lon, "следуйте" по маршруту с использованием внешнего входа (GPS или имитируемого GPS) и разработайте алгоритм, который дает пользовательские инструкции по мере приближения к каждому реальному пересечению. Обратите внимание, что есть больше пар лат/лон, чем инструкции из-за извилистых дорог и т.д., И вам нужно будет определить направление движения и т.д. Множество угловых случаев, которые вы не увидите, пока не попытаетесь его реализовать.

Поиск по интересам.. Это интересно - вам нужно найти текущее местоположение, и все интересующие вас объекты (а не часть TIGER, сделайте свой собственный или получите другой источник) в пределах определенное расстояние (как ворона, или более тяжелое - расстояние движения) от источника. Это интересно в том, что вам нужно преобразовать базу данных POI в формат, который легко найти в этом случае. Вы не можете потратить время на миллионы записей, выполнить расчет расстояний (sqrt (x ^ 2 + y ^ 2)) и вернуть результаты. Вы должны иметь некоторый метод или алгоритм, чтобы сначала сократить объем данных.

Путешественник. Маршрутизация с несколькими пунктами назначения. Только более сложная версия регулярной маршрутизации.

Вы можете найти несколько ссылок на многие проекты и источники информации по этому вопросу здесь.

Удачи, и, пожалуйста, опубликуйте, что бы вы ни делали, независимо от того, насколько они рудиментарны или уродливы, поэтому другие могут принести пользу!

-Adam

Ответ 2

SharpMap - это механизм отображения .NET 2.0 с открытым исходным кодом для WinForms и ASP.NET. Это может обеспечить все необходимые функции. Он имеет дело с наиболее распространенными форматами данных ГИС и растровых данных, включая шейп файлы ESRI.

Ответ 3

решение:

• геопространственный сервер, такой как maperver, geoserver, degree (opensource).

Они могут читать и обслуживать шейп файлы (и многое другое). Например, геосервер (когда установлен) обслуживает данные из шейп файлов TIGER Бюро переписей США в качестве демонстрации

• картографическую библиотеку javascript, такую ​​как openlayers (см. примеры в текст ссылки

В Интернете есть много примеров использования этого решения

Ответ 4

Смешной вопрос. Вот как я это делаю.

Я собираю любую геометрию, в которой я нуждаюсь, в любых форматах, в которые они входят. Я вытаскивал данные из USGS, поэтому это сводится к следующему:

• Файлы SHP (Техническое описание ESPI Shapefile)
• Файлы DBF (Файл данных Xbase (*.dbf))

Затем я написал программу, которая "компилирует" эти определения фигур в форму, которая эффективна для рендеринга. Это означает, что любые преобразования прогнозов и форматов данных необходимы для эффективного отображения данных. Некоторые подробности:

• Для 2D-приложения вы можете использовать любой желаемый прогноз: Map Projections.
• Для 3D, вы хотите преобразовать эти широты/долготы в 3D-координаты. Ниже приведена математика о том, как это сделать: преобразование из сферические координаты к нормальным прямоугольным координатам.
• Разбить все примитивы на квадранты/окте (2D/3D). Листовые узлы в этом дереве содержат ссылки на всю геометрию, которая пересекает граничную рамку node (по оси). (Это означает, что фрагмент геометрии можно ссылаться более одного раза.)
• Затем геометрия разбивается на таблицу вершин и таблицу команд рисования. Это идеальный формат для OpenGL. Команды могут быть выданы через glDrawArrays с использованием вершинных буферов (Vertex Buffer Objects).
• Для прохода quadtree/octree используется общий шаблон посетителя. Прогулка включает проверку того, пересекает ли посетитель данные узлы дерева до тех пор, пока не встретится лист node. Посетители включают: рисование, обнаружение столкновения и выбор. (Поскольку листья дерева могут содержать повторяющиеся ссылки на геометрию, ходок отмечает узлы как посещаемые и игнорирует их после этого. Эти метки должны быть reset или иным образом обновлены перед выполнением следующего шага.)
• Использование системы пространственного разбиения (одного из деревьев) и эффективного представления чертежа имеет решающее значение для достижения высоких кадров. Я обнаружил, что в этих типах приложений вы хотите, чтобы ваша частота кадров была как можно выше 20 кадров в секунду. Не говоря уже о том, что большая производительность даст вам массу возможностей для создания лучшей карты. (Шахта далека от хорошего взгляда, но будет там когда-нибудь.)
• Пространственное разбиение помогает повысить производительность за счет уменьшения количества команд рисования, отправленных процессору. Однако может наступить время, когда пользователь действительно хочет просмотреть весь набор данных (возможно, арийский вид). В этом случае вам нужна система управления деталями. Поскольку мое приложение касается улиц, я отдаю приоритет дорогам и дорогам. Мой код чертежа знает о том, сколько примитивов я могу сделать, прежде чем моя частота кадров снизится. Примитивы также сортируются по этому приоритету. Я рисую только первые x элементы, где x - количество примитивов, которые я могу нарисовать по желаемой частоте кадров.

Остальное - управление камерой и анимация любых данных, которые вы хотите отобразить.

Вот несколько примеров моей существующей реализации:

Изображение http://seabusmap.com/assets/Picture%205.png Изображение http://seabusmap.com/assets/Picture%207.png

Ответ 5

для хранения данных тигра локально, я бы выбрал Postgresql с postgis.

у них есть внушительная коллекция инструментов, особенно для вас Tiger Geocoder предлагает хороший способ импорта и использования данных тигра.

вам нужно будет взглянуть на инструменты, которые взаимодействуют с postgis, скорее всего, какой-то mapserver

из http://postgis.refractions.net/documentation/:

В настоящее время существует несколько инструментов с открытым исходным кодом, которые работают с PostGIS. Проект uDig работает с полной рабочей средой для чтения и записи, которая может работать с PostGIS напрямую. Для интернет-картографии Университет Миннесоты Mapserver может использовать PostGIS в качестве источника данных. Инструментарий GeoTools Java GIS поддерживает PostGIS, также как и сервер веб-функций GeoServer. GRASS поддерживает PostGIS в качестве источника данных. В JMSP Java Desktop GIS viewer есть простой плагин для чтения данных PostGIS, а рабочий стол QGIS имеет хорошую поддержку PostGIS. Данные PostGIS могут быть экспортированы в несколько выходных форматов ГИС с использованием библиотеки OGR С++ и инструментов командной строки (и в курсе с упакованным файловым файлом Shape). И, конечно же, любой язык, который может работать с PostgreSQL, может работать с PostGIS - список включает Perl, PHP, Python, TCL, C, С++, Java, С# и т.д.

edit: depate mapserver, имеющий слово SERVER в своем имени, это будет использоваться в среде рабочего стола.

Ответ 6

Хотя вы уже решили использовать данные TIGER, вас может заинтересовать OSM (Open Street Map), beacuse OSM имеет полный импорт данных TIGER в нее, обогащенный пользовательскими данными. Если вы придерживаетесь формата TIGER, ваше приложение будет бесполезно для международных пользователей, а OSM вы получите TIGER и все остальное сразу.

OSM - это открытый проект с совместной редактируемой свободной картой мира. Вы можете получить все эти данные, а также структурированный XML, либо запрос для региона, либо загрузить весь мир в большой файл.

Есть некоторые средства отображения карт для OSM, доступные на разных языках программирования, большинство из которых с открытым исходным кодом, но все еще многое предстоит сделать.

Существует также служба маршрутизации OSM. Он имеет веб-интерфейс и может также быть запрошен с помощью API веб-сервисов. Опять же, это не все закончилось. Пользователи могут определенно использовать приложение для настольных компьютеров или мобильных маршрутов, построенное поверх этого.

Даже если вы не решите пойти с этим проектом, вы можете получить от него много вдохновения. Просто взгляните на вики проекта и на источники различных программных проектов, которые задействованы (вы найдете ссылки на них внутри вики).

Ответ 7

Вы также можете работать с Microsoft Visual Earth mapping application и api или использовать Google api. Я всегда программировал коммерчески с продуктами ESRI и не играл с открытым api.

Кроме того, вы можете посмотреть на Maker! и Finder! Это относительно новые программы, но я думаю, что они свободны. Может быть ограничено вложением данных. Maker можно найти здесь.

Проблема заключается в том, что пространственная обработка является довольно новой в некоммерческом масштабе.

Ответ 8

Когда я дал этот ответ, вопрос был помечен

"Каким будет лучший способ визуализации Shapefile (данные карты) с помощью полилиний в .Net?"

Теперь это другой вопрос, но я оставляю свой ответ на исходный вопрос.

Я написал версию .net, которая могла бы рисовать векторные данные (такие как геометрия из файл shp), используя простой GDI + в С#. Это было довольно весело.

Причина в том, что нам нужно было обрабатывать различные версии геометрии и атрибуты с большим количеством дополнительной информации, чтобы мы могли не использовать коммерческий компонент карты или с открытым исходным кодом.

Главное, когда это делается создать окно просмотра и переводить/преобразовывать координаты WGIS84 к уменьшенному масштабу и GDI + x, y координаты и ждать с проекцией если вам вообще нужно перепрограммировать.

Ответ 9

Если вы не против платить за решение Safe Software производит продукт под названием FME. Этот инструмент поможет вам перевести данные из любого формата в любой другой. Включая KML в формат Google Earth или отображая его как JPEG (или серии JPEG). После преобразования данных вы можете вставлять google earth в свое приложение, используя API или просто отображать черепичные изображения.

Как сторона не FME - очень мощная платформа, поэтому при выполнении ваших переводов вы можете добавлять или удалять части данных, которые вам не нужны. Объедините источники, если у вас их несколько. Преобразование координат (я не помню, что именно использует Google Earth). Храните резервные копии в базе данных. Если серьезно, если вы готовы выложить несколько долларов, вы должны изучить это.

Вы также можете создавать флаги (как и на вашей карте выборки), которые содержат местоположение (где его помещать) и другие данные/комментарии о местоположении. Эти флаги бывают разных форм и размеров.

Ответ 10

Одно упрощение над Меркатором или другой проекцией - это принять постоянный коэффициент преобразования для широты и долготы. Умножьте градусы широты на 69.172 миль; для долготы, выберите среднюю широту вашей области карты и умножьте (180-долготу) на косинус (средняя) * 69.172. Когда вы перейдете в мили, вы можете использовать другой набор преобразований, чтобы получить координаты экрана.

Это то, что сработало для меня еще в 1979 году.

Мой источник для количества миль на градус.

Ответ 11

Одним из решений является использование MapXtreme. У них есть API для Java и С#. API может загружать эти файлы и отображать их.

Для Java:

http://www.mapinfo.com/products/developer-tools/desktop%2c-mobile-%26-internet-offering/mapxtreme-java

Для .NET:

http://www.mapinfo.com/products/developer-tools/desktop%2c-mobile-%26-internet-offering/mapxtreme-2008

Я использовал это решение в настольном приложении, и он работал хорошо. Он предлагает гораздо больше, чем только предоставление информации.

Теперь делать это с нуля может занять довольно много времени. У них есть оценочная версия, которую вы можете скачать. Я думаю, что он просто печатает "MAPXTREME" над картой в качестве водяного знака, но он полностью можно использовать в противном случае