Как стать автором
Обновить

Комментарии 28

Очень жаль что вы опустили описание установки PostgreSQL и самого postgis. Потому как например просто поставить пакет postgis недостаточно и команда create extension postgis не сработает. Может конечно что то у меня с руками, но ни в Ubuntu 14 ни на FreeBSD 9/10 postgis так не заводится. Необходимо руками запускать sql скрипты, добавляющие расширение и необходимые функции и типы данных postgis
Я ж ровно это и написал

Необходимо руками запускать sql скрипты, добавляющие расширение и необходимые функции и типы данных postgis
Я специально пропустил описание установки. Иногда все работает с первого раза, иногда что-то идет не так. У меня проблемы были связаны с тем, что на машине было одновременно установлено несколько версий Postgres и расширение postgis, устанавливалось не в ту версию. Решил радикально, оставив только одну версию Postgres.
PostGIS 2.0+ на моей памяти обычно устанавливается без проблем. Это с 1.5 нужно было вручную таблицы импортировать.
OpenStreetMap использует PostGIS для хранения своих карт (хотя бы потому, что PostGIS — это база), а не для их отображения.
По ссылке на «саму карту» на сайте GeoFabrik находится не карта, а дамп базы в специальном блочном формате, облегчающем произвольный доступ.

Карта — это картинка, изображение местности. OSM — это не картинка (и не карта), а картографическая база данных. Если бы большинство тех, кто участвует в этом проекте и тех, кто пытается работать с этими данными это понимали, у OSM несколькими проблемами было бы меньше.
Спасибо за пояснение в терминологии. Впредь постараюсь точнее выражаться.
OSM — это не картинка (и не карта), а картографическая база данных.

Кажется OSM немножко по-другому себя позиционирует:
OpenStreetMap is a map of the world


В статье я, как вы правильно отметили, пишу о файле картографической базы данных, а не о карте.
То, что там написано — это всего лишь слоган, который по мнению тех, кто его писал, должен, видимо, звучать очень круто. На самом деле, от него больше вреда, чем пользы. Например, OSM постоянно сравнивают с Google Maps или картами Яндекса. А тем временем, сравнивать этот проект нужно с коммерческими поставщиками данных вроде Navteq, Teleatlas и так далее, названия которых почти никто не знает.

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

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

В таком виде он вполне сравним с Google и Яндекс. Причем существенно выигрывает у них, за счет меньших ограничений на использование данных, а также возможности поднять на своих серверах необходимые сервисы.
Я в курсе этой схемы, а также в курсе того, что часть вещей, которые на ней нарисованы, представляют из себя только некий пример. (К слову, схема устарела, на ней еще OpenLayers на osm.org) И я в курсе, что существует «дефолтный Mapnik», который представляет из себя на деле не более чем технологическую визуализацию. Сравните его, скажем, со стилем OpenMapSurfer или Чепецк.net и поймете, на сколько он рудиментарный.

Упомянутые в схеме TileMill, «transport renderer», «mapquest renderer» вообще не являются непосредственно частями проекта. Как, впрочем, и демонстрационный Nominatim на том же osm.org.

Наличие этой технологической визуализации и поиска с предельно ограниченным функционалом только вводят в заблуждение тех, кто не в курсе всей кухни.
Еще совсем недавно качество OSM картографической базы было неудовлетворительным для промышленного использования. Возможно уже скоро рендеринг и поиск значительно улучшаться. И не последнюю роль в этом сыграет правильное позиционирование.
На чем основаны эти ваши предположения? Вы разве что-то знаете о «политической» стороне проекта? Вот сейчас в OSMF творится не то чтобы бардак, но разброд и шатание. Не слишком подходящая обстановка для того, чтобы что-то улучшилось в этом аспекте. Да и задача такая не стоит. OSM — поставщик данных, а не сервис вроде Google Maps.
Google и Яндекс это лишь фиолетовая часть картинки, да и то не вся. Поэтому как сравнивать 1/5 с целым не понятно.
Я не знаю, как Google, но Яндекс точно делает свои карты и у него есть собственный штат картографов. Я правда не в курсе какими чужими картами он пользуется. Так, что Яндекс не ограничивается фиолетовой частью.
А вы поинтересуйтесь на досуге, прежде чем что-то утверждать на эту тему.
А ST_Point действительно нужно задавать параметры в «мы-не-такие-как-все» порядке, или это опечатка? Потому что (30.3250575, 59.9174455) — это Аравия, если lat-long.
Я так понимаю, что в российской традиции lat-long, а в англо-американской наоборот long-lat и по-умолчанию в ST_Point long-lat.
Всероссийский народный сервер maps.google.com интерпретирует два float через запятую как lat-long.
Зря я полез в традиции. Вот дока на ST_Point там lon-lat
В подавляющем большинстве ГИС координаты указываются как X, Y, (Z). Для большинства систем координат это longitude, latitude. (Можете посмотреть QGis, ARCGis, PostGIS, Oracle Spatial, Автокад и т.д. )

Порядок lat-lon в прикладных задачах, — это видимо дань традиции, причем очень старой, когда для определения lat достаточно было секстанта. Определение-же долготы — отдельная, увлекательная история: domir.ru/other/?file=greenwich-time-1.php
> В подавляющем большинстве ГИС координаты указываются как X, Y, (Z). Для большинства систем координат это longitude, latitude.

Не смог распарсить смысл. Вы имеете в виду, что производители ГИС договорились сообща издеваться над обычными людьми, которые с детства привыкли к lat-long порядку? Ну ОК. Потому что я не понимаю, чем это λ вдруг первее φ, и с каких пор углы принято именовать обычной для декартовской системы координат латиницей.
с каких пор углы принято именовать обычной для декартовской системы координат латиницей.


Примерно со времен разработки проекции Меркатора.
Я всегда считал, что в развертке цилиндра используется декартовская двумерная система координат без углов (и основная цель проекции Меркатора как раз заключается в избавлении от углов).

Ошибался, наверное.
Не путайте непроецированные угловые координаты в градусах и проецированные в EPSG:4326 (которая де-факто стандарт индустрии). Численно они равны, но в EPSG:4326 цифры означают декартовы x и y. Чтобы не было соблазна и быстрее выявлять ошибки в восприятии, некоторый софт (proj4/pyproj, например) принципиально хранит угловые координаты только в радианах.
С чего вы решили, что я что-то путаю? Я всегда с уважением отношусь к стандартам индустрии. Но вот в описании функции мы видим: «ST_Point(float x_lon, float y_lat)».

Поправьте меня, если я ошибаюсь, но «lon» это сокращение от longitude, а «lat» — от latitude. У этих слов, вне зависимости от индустрии, есть словарные значения: www.merriam-webster.com/dictionary/latitude и www.merriam-webster.com/dictionary/longitude.

Но вообще стоило бы раскрыть работу и возможности с этим типом Geometry в PostGIS.
Документацию повторять не хотелось, поэтому я привел пример только одного конструктора ST_Point. Из возможностей ограничился хранением OSM базы в postgres. Понятно, что за рамками осталось очень много, но всего сразу не охватить.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории