Преобразование geometry type

Натолкнулся на проблему преобразования из geometry типа
osmosis перегоняет osm файл в postgre, причем преобразовывая долготу и широту в формат geometry
для примера:

select * from nodes where id = 319852474;
id | version | user_id | tstamp | changeset_id | geom
-----------±--------±--------±--------------------±-------------±---------------------------------------------------
319852474 | 1 | 21417 | 2008-12-19 01:27:47 | 468495 | 0101000020E6100000320395F1EF873E402D05A4FD0F204B40
(1 row)

каким образом можно geom значение преобразовать обратно в latitude и longitude ?

зайдите в таблицу node_tags, будете приятно удивлены - там и широта, и долгота есть в чистом виде. колонка geom - дополнительная, это те же координаты в WKB. Из которого, в принципе, конвертировать-то можно, только в данном случае - не нужно.

http://gis-lab.info/docs/postgis/manual/index.html
‘select st_x(geom), st_y(geom) from nodes where id = 319852474;’ должно помочь, если действительно они нужны из этой таблицы

\d node_tags
Table “public.node_tags”
Column | Type | Modifiers
---------±-------±----------
node_id | bigint | not null
k | text | not null
v | text | not null
Indexes:
“idx_node_tags_node_id” btree (node_id)

видимо несколько некорректно замечание - можно только инфу по ключам k и v вытянуть согласно node_id

красавец!!! что еще можно сказать, спасибо - выручили

тему можно, пожалуй, закрывать

(в дополнение)

select st_x(geom), st_y(geom) from nodes where id = 319852474;
st_x | st_y
-----------±----------
30.531005 | 54.250488
(1 row)

а вот так попробовать религия не позволяет select node_id, lat, lon from public.node_tags ?

Готов спорить, это будет быстрее, чем конвертить WKB…

выше описал таблицу public.node_tags - она попростуне содержит полей lat & lon

еще важен тот аспект, что пользуюсь postgres и может osmosis’ом можно создавать другие таблицы в mysql не знаю и подобных .sql скриптов не видел

тьфу, сории. запрос такой

select v from public.node_tags where node_id = 1 and k = ‘lat’
select v from public.node_tags where node_id = 1 and k = ‘lon’

получаем долготу и широту для искомого узла.

увы но в k нет параметров ни lat, ни lon, так что способ с

не пройдет

Вы базу и xml только не путайте!

Вот только честно, вы пробовали? Попробуйте, вам понравится!

начинаем флейм, потому что запрос базе я скармливал и аналогичные , увы значений ни lat, ни lon нету
пример подобного запроса (большой пример!):

как говорится от слов к делу

Мда…
и кагбы понять, почему у меня запрос

select * from public.node_tags where k = ‘lat’;

(не LIKE, а именно =, я вообще не понимаю, зачем сравнение использовать, когда у ключа четкое имя) , выдает количество вхождение, равное количеству узлов?

Ну и последний вопрос, если в базе нет lat и lon, ТО ОТКУДА ОСМОСИС ИХ ПОСЧИТАЛ В СТРОКУ geom? Так, ради интереса, посмотрите на запросы к базе, которые осмосис делает, он ВСЕ geometry рассчитывает силами Постгиса из данных, которые уже есть в базе!!!

(поясню, что сравнение использовал на тот случай, если в базе вдруг окажется не lat и lon поля, а latitude и longitude)

интересно почему … может дело в используемом API или даже postgis tasks, ведь в своей базе использую лишь pgsql_simple_schema_0.6.sql
на оффсайте: http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#PostGIS_Tasks

Не может такого быть. Эти данные от схемы не зависят, это аттрибуты каждой точки и они у вас есть, иначе у вас не было бы колонки геометрия. Осмосис не считает геометрию сам ,он это делает силами постгиса из данных, имеющихся В БАЗЕ. Так что еще раз запустить приведенный выше запрос и убедитесь, что эти данные у вас ЕСТЬ!

мне в общем не сложно написать это еще раз :

select * from public.node_tags where k = ‘lat’;
node_id | k | v
---------±–±–
(0 rows)

я в шоке… Ну откуда тогда колонка geom посчиталась?

geom для скорости и удобства - в ней и содержатся ведь координаты - функции st_x(geom) st_y(geom) и помогают вытянуть lat и lon

думаю можно считать итогом этой ветки

Блин… geom не могла правильно посчитаться, если нет в node_tags lat и lon. Потому что она из них считается. Если их там нет - geom неверная! (То есть вообще должна быть пустая). Если у вас нет части данных - значит у вас неверно прошел импорт (хотя ума не приложу как так могло получиться!) Значит у вас может нехватать еще каких-то данных!!! То есть база НЕ ВАЛИДНАЯ!!!

подтверждаю валидность базы, следующими фактами

из базы выдрал первое попавшееся значение нода:

gisdb=# select id, version, user_id, tstamp, changeset_id, geom from nodes where id = ‘243055735’;
id | version | user_id | tstamp | changeset_id | geom
-----------±--------±--------±--------------------±-------------±---------------------------------------------------
243055735 | 8 | 21417 | 2009-02-01 00:22:40 | 858930 | 0101000020E6100000C2DD59BBED723D403FA9F6E978F44B40
(1 row)

gisdb=# select id, version, user_id, tstamp, changeset_id, st_x(geom), st_y(geom) from nodes where id = ‘243055735’;
id | version | user_id | tstamp | changeset_id | st_x | st_y
-----------±--------±--------±--------------------±-------------±---------±---------
243055735 | 8 | 21417 | 2009-02-01 00:22:40 | 858930 | 29.44894 | 55.90994
(1 row)

лезу в osm файл и убеждаюсь:

Значения lat и lon идентично значениям st_x(geom) и st_y(geom)

Подтверждать чем-либо валидность базы, в которой доказано отсутствуют данные, которые там должны быть, нонсенс. Откуда вы знаете, что вместе с данными лат/лон не пропало что-то еще???

Upd. В любом случае, пользоваться базой вам, так что решайте сами. Только огромная просьба - не вносите ОБРАТНО в ОСМ данные, построенные на основе вашей базы, ибо это чревато ошибками!

если можно пример приведите вывода своего запроса
select * from public.node_tags where k = ‘lat’ limit 20; – к чему стремится так сказать

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