Консультации на тему PostGIS

Доброго времени суток.
Прошу прощения за столь поздний ответ.
Не так давно решал (да и сейчас продолжаю) полностью аналогичную задачу. Но мы остановились на gvSig'е. Архитектура простая: каждый конкретный вид сетей хранится в своей отдельной базе (PostgreSQL/PostGIS) со своим пользователем. Все сети и подложка объединены в один WMS-сервис для показа (просмотра) Клиент-редактор коннекится к своей базе и правит свои слои. При внесении изменений информация сразу отображается на подложке у всех. Вкратце все. За подробностями на мыло.

> Обдумываю клиент для визуализации слоев
- а я уже навзуализировался досыта.
Однозначно WKB, причем NDR
(парсинг текста займет столько процессорного времени, что прикладного смысла твоей проге найти не удастся)
Если пишеш на С - у тебя все типы данных под рукой, если на другом языке - опиши структуры-заголовки примитивов, напиши функции преобразования из WKB в формат, принимаемый GDI и вперед. В отрисовке ничего военного нет, изучи (повтори) теорию GDI и яростно следи за утечкой GDI-объектов (10000 и приложение вылетает). Рекомендую больше думать об общей архитектуре приложения и о тех прикладных задачах, которое оно сможет решать. Просто просмотр никому не интересен.

Доброго времени суток, Олег.

Очень просто:
а) берете внешнее кольцо полигона и, поскольку оно замкнутое (первая и последняя точка совпадают) -
б) удаляете последнюю точку.

Взять внешнее кольцо полигона: ExteriorRing(geometry)
Удалить точку: removePoint(geometry, integer)
Количество точек: nPoints(geometry)
( ну или все в префиксом "st_" если Вам так больше нравится)
Пример 1 (функциональный):
SELECT removePoint(closed_line, nPoints(closed_line)-1) AS open_line FROM (
SELECT ExteriorRing(object) AS closed_line FROM map_table
)q;

Пример 2 (наглядно посмотреть координаты):

SELECT AsText(object) AS PolygonOriginal, AsText(closed_line) AS ExteriorRing, AsText(open_line) AS result FROM (
SELECT object, closed_line, removePoint(closed_line, nPoints(closed_line)-1) AS open_line FROM (
SELECT object, ExteriorRing(object) AS closed_line FROM map_table
)q
)z;

писал на скорую руку, может не совсем оптимально, но 100% работает ( PostgreSQL 8.3.3, PostGIS 1.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1)

DDL таблички:

CREATE TABLE map_table
(
id SERIAL NOT NULL,
"object" geometry,
CONSTRAINT map_pg_pk PRIMARY KEY (id),
CONSTRAINT enforce_dims_object CHECK (ndims(object) = 2),
CONSTRAINT enforce_geotype_object CHECK (geometrytype(object) = 'POLYGON'::text OR object IS NULL),
CONSTRAINT enforce_srid_object CHECK (srid(object) = 4326)
);

Доброго времени суток, Саша.
Пункты 1..3 абсолютно правильны. Хочу только заметить, что под Delphi следует использовать порядок байт NDR:

SELECT ... AsBinary(the_geom, 'NDR') FROM ...

и закрывать транзакцию я предпочитаю командой END. Она является полным синонимом COMMIT, но, с.м.л.т.з, является более "благозвучной", т.к. мы ничего не изменяем в базе и, следовательно, ничего не коммитим.

4) ..используем методы ... канвы TBitmap.. - неверный подход. Тут затык по скорости жуткий будет. Пока объектов немного (десяток-два)- все в принципе работает хорошо. Но когда надо отрисовать пару тысяч и стоИт временной лимит - будет, скажем так, полный пэ. Рекомендую использовать нативное GDI API, а рисовать на DC, только нужно внимательно следить за утечкой GDI-объектов. В таких программах она опаснее, чем утечка памяти.

5) в файле wkb.h в сырцах постгиса. Перевести их один-к-одному на Pascal не получится, придется работать с указателями.

6) А чем AsBinary(some_line, 'NDR') не массив точек?:

typedef struct WKBLineString_t {
  byte byteOrder;
  uint32 wkbType; // 2
  uint32 numPoints;
  Point points[1]; // [numPoints]
} WKBLineString;


Или нужно получить каждую точку в отдельной строке резалтсета? Опишите прикладную задачу..

>>Или проще каждый объект обрабатывать на стороне клиента и обновлять строку исправленным объектом ?
- Ну зачем же дурно гонять данные на клиента и назад? Все эти вопросы можно решить на стороне БД, либо родными средствами PostGIS (правда придется валидаторы самому писать на SQL и/или PL/SQL), либо прикрутить готовую стороннюю библиотеку (вот, правда, готовых не подскажу).

Кстати о валидаторах. Ошибки конфигурации геометрии только кажутся типичными. Но это не так, ибо в общем случае неизвестно, что именно за данные хотелось представить данным набором координат и откуда собственно взялось нарушение конфигурации. По-этому, валидаторы зачастую нужно писать (или подгонять) для каждой конкретной задачи. Если найдете готовые, которые смогут решить вашу задачу - кричите ура ибо удача!

• повторение точек в контурах

- покопайте в сторону st_simplify. Задавая маленький tolerance вы сможете сохранить конфигурацию геометрии (т.е. она может измениться, но за нижним пределом значимого диапазона, например за шестым знаком) и уберете все повторения. Толеранс подбирать эксперементально.

• самопересечение

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

• касание

- хм.. обычно ошибкой считается отсутствие касания, там где оно действительно нужно (граф улиц, земельные участки ...). Если оно есть там, где оно не нужно - исправить это можно, пожалуй, только руками (с участием мозга).

• полигоны с нулевой площадью

- если периметр полигона с нулевой площадью [заметно] отличен от нуля - преобразуйте полигон в линию (из внешнего кольца). Если же и периметр нулевой - преобразуйте в точку.

..тян фирма (:
сходите сюда: http://sigma-ltd.net/
(Дмитрич, если спец хороший - с тебя пиво :D )

Доброго времени суток.
Вариантов два - либо это невалидные полигоны, либо баг QGIS и Mapserver'а (что, к сожалению, вероятнее). Я сталкивался и с тем и с другим. Во втором случае остается надеяться разве что на то, что в к следующему билду исправят :) [чего, как правило, не происходит :) :) ]
Если выгрузить полигоны в shape-файлы и открыть чем-то "путёвым", например ArcView - как отображаются полигоны?
Что возвращает ST_IsValid для этех полигонов? Если false - вызовите ST_IsValid для каждого кольца полигона отдельно (для внешнего и всех внутренних) не забыв при этом преобразовать LINESTRING'и в POLYGON'ы - так вы найдете битое кольцо. Если нет - значит пересекаются разные кольца. В любом случае, невалид нужно найти и исправить.
Если же полигоны валидны и имеет место баг отображения -рекомендую разбить их на максимально простые объекты. Отображению это должно помочь, а вот логика приложения пострадает, т.к. для одного логическог объекта у вас будет несколько записей в БД. Из этой ситуации можно выйти только перекраиванием структуры БД, например:

-- для логических объектов создаем таблицу вида
CREATE TABLE logical_object(
  id serial PRIMARY KEY,
  some_attribule sometype, -- любые аттрибуты
  metric  GEOMETRY -- метрика объекта - его "правильная", сложная геометрия, используемая для анализа и решения прочих логических задач
) WITH (OIDS=true);

-- Идея наша в том, чтобы сложный в отрисовке объект разбить на ряд простых.
-- Создаем таблицу для хранения таких простых объектов и их связи с логическим объектом
CREATE TABLE drawing(
  id serial PRIMARY KEY,
  object_id integer, -- ссылка на логический объект (logical_object)
  drawing_obj GEOMETRY -- собственно, простой элемент для отрисовки
  CONSTRAINT drawing_logical_object_fk FOREIGN KEY(object_id) REFERENCES logical_object (id) ON DELETE CASCADE
) WITH (OIDS=true);

-- связываем обе таблицы представлением:
CREATE VIEW drawing_layer AS
  SELECT d.oid as oid, -- всякие мапсерверы и квантумы жить не могут без этого поля (:
      d.drawing_obj as DrawingId,
      lo.id as ObjectId,
      d.drawing_obj as geom
      [,lo.some_attribule]
  FROM drawing d, logical_object lo
  WHERE lo.id = d.object_id;
-- Само предстваление нужно не забыть добавить в geometry_columns

** SQL был набросан "от руки", только для того, чтобы передать идею и на работоспособность не проверялся.

Если опишите свою структуру данных и задачу - смогу подсказать конкретнее.

фуф, тыщу лет этим не занимался - уже забыл, что такое 1251 :)
стандартного решения увы нет, но есть обходные. Медленный но надежный - сохраняете бекап в обычном SQL с INSERT (не COPY) командами, текстовый файл перегоняете из 1251 в утф и восстанавливаете. Долго, дорого, охуенно, дешево и сердито.
перекодировать файл нужно, ясное дело, не текстовым редактором (если гектарный бекап - любой редактор его и открыть-то не сможет) - гугл знает утилиты.

можно функциями конвертации строк переодировать в самой бд, но это более мутно.