Может подскажет кто. Почему osm2pgsql может не загрузить точку из данных? Смотрю загрузку osmosis-ом точка есть, osm2pgsql - нет. Соответственно и дорога поличилась обрезана. например node - 2246232221, way - 215216040
64-битные ID в некоторых сборках по умолчанию выключены, особенно если под Windows 
Кто-нибудь знает рабочую сборку, кроме моей экспериментальной из предыдущего поста?
А там случаем не составная дорога? один и тот же osm_id могут иметь несколько рядов в таблицах
Да нет, обычная дорога. В JOSM немного её обновил, теперь нормально. а было так:
поторопился с нормально 
vs
Запрос
select osm_id from (нужная таблица) where osm_id>2150000000
что-нибудь выдает? Если нет, то проблема с 64бит ID.
Выдает. Смущает вот это:
select * from planet_osm_ways where id = 215288977;
id | nodes | tags | pending
-----------+----------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------+---------
215288977 | {2246913140,2379011215,2246913145,2246232221,2246232218,2246913148,2246913147,2246232215,2246232213,2687582891,2246232210} | {surface,unpaved,name,"Дачная улица",highway,service} | f
и
gis=# select * from planet_osm_ways where id = 215216043;
id | nodes | tags | pending
-----------+---------------------------------------------------------------------------+-------------------------------------------------------------+---------
215216043 | {-2048735089,-1915956082,-2048054156,-2048735096,-2048735093,-2048735092} | {surface,paved,name,"Просторная улица",highway,residential} | f
Вот эти точки с минусом они есть и в planet_osm_nodes хотя вроде должны быть другие цифирки. Это так и должно быть?
система Debian Wheezy amd64, версия osm2pgsql: 0.80.0+r27899-4
А в .osm-файле отрицательные ID есть?
Если да:
В OSM-файле, сохраненном в JOSM, минусы означают новые объекты, сервер присвоит им ID при аплоаде. Не факт, что osm2pgsql их полностью поддерживает.
Если нет (более вероятно):
IDшники -2048735089,-1915956082,-2048054156,-2048735096,-2048735093,-2048735092
очень похожи на проблему 64 бит (было чуть больше +2148…) , но она какая-то частичная (другие ID-то в порядке). Возможен баг в osm2pgsql или в сочетании с какими-то другими библиотеками системы (если что-то из libxml2 / protobuf / protobuf-c запортило большие ID)
Нужно мнение эксперта. Ну и хорошо бы мелкий OSM-файл с проблемными данными для проверки.
Он начинает с -1, -2 …, врятли он создал 2ккк объектов прежде чем решил сохраниться.
Да ктож его теперь знает. Это был local.pbf с gis-lab
похоже на то. точек с отрицательным id 42697905 из 199222491. Попробую воспроизвести загрузку.
Кстати, можно попробовать считать не только из pbf, но и из раскодированного osm (вдруг проблема в pbf-читалке или цепочке protobuf/protobuf-c).
Здравствуйте.
Спасибо за советы в этой ветке - на Линуксе все работает здорово. Но, теперь возникли проблемы с Виндой.
По инструкции сделал БД на Линуксе (кодировка UTF-8, сопоставление UTF-8, символы - UTF-8). Соответственно в запросе Ru_ru.UTF-8.
Теперь мне нужно сделать аналогичную БД на Виндовс 7 (х86 Начальная). Я пошел простым путем - экспорт (линукс) импорт (Виндовс).
На Винде, создаю новую БД, тут первая проблема - локали Russian_russian.utf нет, следовательно метод сопоставления и символов - Russian_russian.1251.
При этом, при запросах в sql терминале pgAdmin - кириллица в данных есть. Все ок и отлично.
Но, ПО на котором я работаю, работает исключительно в UTF и с БД работает через ODBC драйвер. В результате, вместо кириллицы у меня идут кракозяблы.
Судя по тому, что при запросах в pgAgent данные в кириллице читаются и сохраняются, а в ПО они получаются в виде кракозяблов, предполагаю данную проблему можно как то поправить запросами… Но возможно ошибаюсь.
Можно ли как то запросы по аэродромам модифицировать так, чтобы данные кодировались в UTF-8?
Вам нужен UTF-8 на базе, если не хотите вносить изменения в клиентское ПО.
Как делался этот шаг? Бякапьте всю базу целиком и восстанавливайте на Винде. pg_dumpall, pgsql в помощь. На вывод pg_dumpall советую натравить потоковый архиватор (gzip). Ну, либо из pgAdmin.
Похоже, не тот теплейт для базы выбрали. Да и не нужно вам создавать новую базу, если перенос осуществите по описанному выше алгоритму. База сама создасться при восстановлении из бякапа.
Все делал через pgAgent. Делал бэкап и восстановление. Везде кодировка БД указана как UTF-8.
Восстановление происходит нормально, т.к. при sql запросах в pgAgent - все работает нормально. Кириллица отображается нормально.
Проблемы возникают в Клиентском ПО, которое работает через ODBC. Точно такой же запрос, как и в pgAgente возвращает кириллицу в виде иероглифов. При этом Клиентское ПО работает строго в UTF-8.
Я хочу попробовать убедиться, что проблема кодировки возникает в Клиентском ПО. Поэтому и спрашиваю - есть вариант во время sql запроса, сразу конвертировать ответ в UTF?
Попробую сейчас сделать бэкап без предварительного создания новой БД.
Отпишусь о результате.
convert_to(‘some text’, ‘UTF8’). Но это потребует изменений клиентского ПО, ибо придется изменять SQL запросы. Поэтому, вам нужно, что бы все данные в базе имели кодировку UTF-8.
Можете изменить и текущую кодировку базы, выполнив запрос
update pg_database set encoding = pg_char_to_encoding('UTF8') where datname = 'you_database_name'
Если табличные данные остались в UTF-8, то прокатит
Спасибо! Все работает. И конвертация налету в запросе тоже.
Вопрос по запросам - мне нужно отрисовать векторную карту. При этом ПО рисует вначале те объекты, запрос которых идет раньше. Т.е. к примеру, если первым запросом я выбираю дороги, а вторым реки, то реки будут нарисованы поверх дорог.
Если у меня БД собрана из ОСМ данных, из скаченного шейп файла, то каким образом мне лучше формировать запросы? Вначале границы региона, затем полигоны растительности, затем водные объекты, дороги, пои?
Может у кого-то есть ссылки на примеры.
Принцип, которым Мапник рисует карты я тоже просматриваю в данный момент.
Я тут вроде бы собрал последний osm2pgsql под Windows (64 bit), Visual Studio 2013 Express:
https://dl.dropboxusercontent.com/u/63393258/osm2pgsql.zip
Говорят, оно быстрее старой версии ворочается. Кто-нибудь может проверить правильность и скорость работы?
(см. также https://github.com/openstreetmap/osm2pgsql/issues/17 )
Новая версия osm2pgsql под Windows:
https://dl.dropboxusercontent.com/u/63393258/osm2pgsql.zip
Инструментарий для сборки со всеми скриптами
https://dl.dropboxusercontent.com/u/63393258/osm2pgsql_builder.zip
(нужны PostgreSql, git, svn и Visual Studio 2013 [express], правим settings.bat под свои пути и запускаем build_all.bat).