Собственно, ситуация простая. Запрос, если это просто связанные таблицы и т.д., отрабатывает нормально. При попытке выразиться sel ect <....> fr om <stored proc(<args>)> Panorama13 успешно проверяет запрос, видит имена полей. Но ни она, ни апсервис, данных из такого селекта не получают. Проверил на QGIS, тот подхватывает без проблем. Вопрос - как получить данные Панорамой от хранимой постгресовской процедуры.
Не открываются данные из любых SQL-запросов или только из функций?
Можно увидеть, что возвращает Ваша функция (интересует строка "RETURNS ...")?
Попробуйте после запуска ГИС Панорама 13 включить журналирование операций: гл.меню - Параметры - Журнал диагностики. Затем попытаться открыть dbm - лог будет находиться по пути, указанном в диалоге "Размещение данных" (гл.меню - Параметры - Размещение данных), см. поле "Путь к журналу диагностики". Просьба выслать этот лог нам на e-mail техподдержки panorama@gisinfo.ru (перед выполнением указанных действий, если Вы до этого уже включали журнал диагностики, желательно его почистить).
CREATE OR REPLACE FUNCTION public."GX_VIEW_BOUNDARIES" (
cadnum_prefix varchar = '32:20'::character varying
)
RETURNS TABLE (
id bigint,
geom public.geometry,
excode integer
) AS
$body$
declare rec record;
BEGIN
for rec in
select ob."ID",ob."NUMBER",ob."XML_CADNUM",b."DESCRIPTION",b."NATIVE_NAME",geo."GEOM",st_geometrytype(geo."GEOM") as "GTYPE"
fr om "GX_OBJECTS" ob, "GX_GEOMETRIES" geo, "GX_BOUNDARIES" b
where
ob."ID_TYPE" = 1 and
geo."ID_OBJ" = ob."ID" and
b."ID_OBJ" = ob."ID" and
ob."XML_CADNUM" like cadnum_prefix||'%'
loop
select
case
when rec."GTYPE" like '%Polygon' then 10501
else 10502
end into excode;
id := rec."ID";
geom := rec."GEOM";
return next;
end loop;
END; $body$
Пока предположу, что причина в том, что при работе с функцией, которая генерирует таблицу "на лету", программа не может определить СК для поля метрики.
Попробуйте указать явно код EPSG используемой у Вас в исходной таблице системы координат (например, 4326 - WGS-84 в градусах):
Цитата
CREATE OR REPLACE FUNCTION public."GX_VIEW_BOUNDARIES" ( cadnum_prefix varchar = '32:20'::character varying ) RETURNS TABLE ( id bigint, geom public.geometry(geometry, 4326), excode integer ) AS .....
Отправил два лога в архиве. Короткий - отработка с storedproc, длинный с просто запросом, с которым все в порядке.
Цитата
Денис Вицко написал: Пока предположу, что причина в том, что при работе с функцией, которая генерирует таблицу "на лету", программа не может определить СК для поля метрики. Попробуйте указать явно код EPSG используемой у Вас в исходной таблице системы координат
Я поглядел лог, как понимаю (догадываюсь), клиент пытается сделать что-то вроде
Код
select ST_AsBinary(ST_Transform("GEOM",3857),'NDR') fr om (select * fr om "GX_VIEW_BOUNDARIES"('32:')) as "PRE"
, где 3857 взято из DBM, подзапрос есть sqltext, а вот проекция каждой выдаваемой геометрии (srid) может быть вообще любая, и оно, разумеется, успешно выполняется из любой оболочки, и корректно выдает, в данном случае, в 3857. У меня там как минимум склад КПТ и выписок по десятку регионов и зон. Естественно, в spatial_ref_sys все эти srid с параметрами забиты, a srid геометрии вычисляется при разборе xml.
Алгоритм работы с данными в части обработки СК и проекций описан в документации. Вы правильно поняли, при извлечении пространственных данных, в каких бы СК они ни были, выполняется их трансформирование к СК выходной карты.
Цитата
Илья Рыбалко написал: У меня там как минимум склад КПТ и выписок по десятку регионов и зон.
При нанесении их совместно на одну карту координаты в любом случае должны быть пересчитаны к одной общей СК и проекции.
Корректная работа dbm с SQL-запросами в 13 версии фактически возможна только для запросов, ограничивающих выборку из реальной таблицы или представления (типа "SELЕCT a, b, c FRОM mytable WHЕRE a < 100"). Допускается При использовании в качестве источника "виртуальных" наборов данных, таких как функции, генерирующие выходные таблицы "на лету", а также при принудительном трансформировании метрики прямо в тексте SQL-запроса, возможны потери СК на уровне обработки таких запросов в программе. В 14 версии эта проблема устранена, там достаточно, чтобы набор данных имел метрику с известной СК (то есть достаточно в функции, выдающей наружу данные в виде таблицы, конкретизировать СК для типа geometry, как я написал выше).
1. Пришлите нам на e-mail техподдержки panorama@gisinfo.ru номера ключей Ваших программных продуктов. Мы проанализируем возможность обновления.
2. Судя по присланным логам, у Вас 13 версия от июня прошлого года. На сайте доступна более свежая версия - от 15.12.2021 г. Рекомендую обновить Ваши версии ПО 13-ой версии до крайних, доступных на сайте. В скором времени мы их уберем и поддержка 13 версии будет прекращена.
3. Попробуйте использовать вместо выборки из функции представление (view) на уровне БД. Теоретически должно сработать даже так:
Код
CREATE OR REPLACE VIEW public."V_GX_VIEW_BOUNDARIES"
AS
SELЕCT id, ST_Transform(geom,3857) as geom, excode FROM public."GX_VIEW_BOUNDARIES"('32:20');
А в DBM можно будет указать это представление в выпадающем списке (как таблицу), либо задать SQL-запрос типа
Код
SELЕCT * FRОM public."V_GX_VIEW_BOUNDARIES";
Но лучше переделать выборку, используемую в функции, для представления таким образом, чтобы наружу попадало поле "XML_CADNUM", и можно будет на уровне DBM задать к представлению условие выборки, например:
Код
SELЕCT * FRОM public."V_GX_VIEW_BOUNDARIES" WHЕRE "XML_CADNUM" LIKE '32:20%';