Идеальная база данных для географических (картографических) данных

Question

Я ищу предложения для идеальной базы данных или структуры данных для хранения карты.По сути, карта состоит из «путей», которые похожи на дороги, пути и т. Д. Пути содержат узлы (которые имеют координаты широты и долготы, а иногда и высоту.)

Любая такая база данных или структура:

1. должен быть в состоянии быстро найти все узлы в ограничительной рамке (миллисекунды)

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

3. должна быть в состоянии найти узлы, которые соединяются напрямую: например, узел, соединяющий два пути

4. может быть только для чтения

5. должен быть компактным (не тратить место впустую) - я смотрю карту Великобритании меньшечем 1 ГБ.У меня есть спутниковая навигация, которая делает это с 800 МБ свободного места на SD-карте.

Сначала я думал о четырех деревьях для хранения путей.Но быстрая реализация сложна, и они не работают для отдельных узлов;все узлы помещаются в наименьший возможный bbox.

(я намеренно использую ту же терминологию Open Street Map, потому что планирую использовать эти данные.)

Answer 1

PostGIS может быть лучшим выбором.Примечание: PostGIS - это PostgreSQL с гео-расширениями.Вы буквально устанавливаете postgres, а затем запускаете различные скрипты, которые добавляют гео-функции и типы.

См. OpenStreetMap информацию о PostGIS .Вы можете загружать файлы / экстракты планет OpenStreetMap в PostGIS с помощью osm2pgsql, и это то, что делается на сервере плиток OpenStreetMap, где запускается рендерер Mapnik.Однако ...

Существует также более сырая схема базы данных для данных OpenStreetMap (таблицы, называемые "узлами" и "путями" и т. Д.). Это то, что main Сервер баз данных OpenStreetMap использует для хранения своих данных.геоданные и разрешение редактирования через API.Это не так умно, когда дело доходит до пространственной индексации и т. Д., Но красиво и просто.Вы можете создать базу данных в этом формате, установив OpenStreetMap API / ruby ​​для сайта на коде rails .Это наиболее надежный способ установки современной версии схемы базы данных (определяется как миграция рельсов ).После этого вы можете запустить инструмент osmosis для заполнения базы данных.

Answer 2

Я бы порекомендовал с PostGIS 1.5 с использованием типа geography , так как он подходит для того, что вы хотите, однако моей единственной заботой об использовании чего-то подобного на встроенном устройстве будет памятьиспользование.

Я создал нечто неопределенно связанное с использованием не ГИС-базы данных (firebird) в Java, и производительность была более чем достаточной для получения точек в ограничивающем прямоугольнике (хотя требовался причудливый SQL, который недело с PostGIS).

Answer 3

PostGIS - не единственная база данных, которая поддерживает геопространственные данные, но цена очень хорошая.Трудно превзойти «бесплатно».

Но есть и другие бесплатные варианты, и у некоторых читателей уже может быть другая система реляционных баз данных, и они хотят использовать этот опыт вместо изучения PostGIS.Любой базы данных, поддерживающей спецификации Open Geographic Consortium (OGC или OpenGeo), будет достаточно для сценария, который вы описываете.

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

Итак, вот список всех известных мне опций:

Пространственная СУБД - бесплатнодоступна опция

• Oracle (с пространственным или локатором) (бесплатная опция: Oracle XE + локатор)
• MS SQL Server (2008 или более поздняя версия) (бесплатная опция: SQL ServerЭкспресс)
• PostGIS

Пространственная СУБД - без дополнительной опции

• DB2 (с Spatial Extender)
• Informix (с пространственным блейдом)

Менее идеальной пространственной СУБД

• MySQL Spatial (очень ограниченный набор функций)

Пространственное "Расширение-Ware"

• ArcSDE (выдобавить его в существующую СУБД)

Answer 4

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

Я бы сказал, что Quadtree - действительно хороший вариант для обработки геопространственных данных, кажется, что квадраты становятся слишком маленькимииз того, что я могу сказать.Вы можете сделать границы более мягкими (позволить узлу находиться в двух листьях Quadtree) и добавить минимальное количество узлов на лист.Предположим, что ни одному листу не разрешено содержать менее 64 узлов и не более 1024.

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

Answer 5

Я не уверен насчет пространства, но вы можете рассмотреть возможность использования любого расширения Geo для общих серверов баз данных (если это вообще возможно). Они обычно предлагают быструю географическую индексацию, ограничивающую рамку (ответ на 1 и 2), множество географических процедур для расчетов (ответ на 3, intersect(way1,way2)).

Кроме того, ваш вопрос лучше подходит для http://gis.stackexchange.com