A especificação OpenGIS define dois caminhos padrões de objeto espacial de expressão: a forma Well-Known Text (WKT) e a forma Well-Known Binary (WKB). Ambos, WKT and WKB, incluem informação sobre o tipo do objeto e as coordenadas a qual forma o objeto.

Exemplos das representações de texto das características são como segue:

A especificação de OpenGIS requer também que o formato de armazenamento interno de objetos espaciais inclui um identificador de sistema referenciado espacial (SRID). O SRID é requerido ao criar objetos espaciais para a inserção no banco de dados.

Input/Output desses formatos está disponível usando as seguintes relações:

	bytea WKB = asBinary(geometry);
	text WKT = asText(geometry);
	geometry = GeomFromWKB(bytea WKB, SRID);
	geometry = GeometryFromText(text WKT, SRID);
	

Por exemplo, uma declaração válida de inserção para criar e inserir um objeto espacial de OGC seria::

	INSERT INTO SPATIALTABLE (
	THE_GEOM,
	THE_NAME
	)
	VALUES (
	GeomFromText('POINT(-126.4 45.32)', 312),
	'A Place'
	)

Somente o formato OGC suporta geometria 2d, e o SRID associado *nunca* faz parte das respresentações do input/output.

Formatos de extensão Postgis são atualmente superset de um OGC(cada WKB/WKT válido é um EWKB/EWKT válido), mas mas isto pôde variar no futuro, especificamente se OGC saísse com um formato novo que opõe a nossas extensões. Assim você NÃO DEVE confiar nesta característica!

Postgis EWKB/EWKT soma o suport a coordenadas 3dm,3dz,4d e faz parte das informações SRID.

Exemplos das representações do texto (EWKT) dos objetos espaciais estendidos das características são como segue:

Input/Output desses formatos são usados conforme a interface a seguir:

	bytea EWKB = asEWKB(geometry);
	text EWKT = asEWKT(geometry);
	geometry = GeomFromEWKB(bytea EWKB);
	geometry = GeomFromEWKT(text EWKT);
	

Por exemplo, uma declaração válida de inserção para criar e inserir um objeto espacial seria:

	INSERT INTO SPATIALTABLE (
	THE_GEOM,
	THE_NAME
	)
	VALUES (
	GeomFromEWKT('SRID=312;POINTM(-126.4 45.32 15)'),
	'lugar'
	)

A "canonical form" (forma canônica ) de um tipo PostgreSQL são as representações que pega com uma simples "query" (sem uma chamada de função) e no qual é garantido para ser aceito com uma inserção simples, atualização ou cópia. Para o postgis tipo 'geometry' são esses:

	- Output -
	binary: EWKB
	ascii: HEXEWKB (EWKB in hex form)

	- Input -
	binary: EWKB
	ascii: HEXEWKB|EWKT
	

Para o exemplo esta indicação lê EWKT e retorna HEXEWKB no processo do input/output canônico do ascii:

	=# SELECT 'SRID=4;POINT(0 0)'::geometry;
	geometry
	----------------------------------------------------
	01010000200400000000000000000000000000000000000000
	(1 row)
	

4.1.3. SQL-MM Part 3

A especificação Espacial de Aplicações de Multimedia do SQL estende as simples características para especificações do SQL, definindo um número de curvas inseridas circularmente.
As definições SQL-MM incluem  coordenadas 3dm, 3dz e 4d, mas não permite embutir informação SRID.
The well-known text extensions are not yet fully supported. Examples of some simple curved geometries are shown below:
As extensões de texto conhecidas não são suportadas ainda por completo. Os exemplos de algumas geometrias curvadas simples são mostrados abaixo:

A definição da Tabela de Sistemas de Referências Espacial (SPATIAL_REF_SYS) é como segue:

CREATE TABLE SPATIAL_REF_SYS (
 SRID INTEGER NOT NULL PRIMARY KEY,
 AUTH_NAME VARCHAR(256),
 AUTH_SRID INTEGER,
 SRTEXT VARCHAR(2048),
 PROJ4TEXT VARCHAR(2048)
)

As colunas SPATIAL_REF_SYS são como segue:

A definição de Tabela de Colunas Geométricas (GEOMETRY_COLUMNS) é como segue:

CREATE TABLE GEOMETRY_COLUMNS (
 F_TABLE_CATALOG VARCHAR(256) NOT NULL,
 F_TABLE_SCHEMA VARCHAR(256) NOT NULL,
 F_TABLE_NAME VARCHAR(256) NOT NULL,
 F_GEOMETRY_COLUMN VARCHAR(256) NOT NULL,
 COORD_DIMENSION INTEGER NOT NULL,
 SRID INTEGER NOT NULL,
 TYPE VARCHAR(30) NOT NULL
)

As colunas são como segue:

Criação de uma tabela com dados espaciais é feito em duas fases:

Existe um exemplo de SQL usado para criar tabela e adicionar uma coluna espacial (assumindo que um SRID de 128 já existe):

CREATE TABLE parks ( PARK_ID int4, PARK_NAME varchar(128), PARK_DATE date, PARK_TYPE varchar(2) );
SELECT AddGeometryColumn('parks', 'park_geom', 128, 'MULTIPOLYGON', 2 );

Existe outro exemplo, usando o tipo "geometry" genérico e o indefinido SRID de valor -1:

CREATE TABLE roads ( ROAD_ID int4, ROAD_NAME varchar(128) );
SELECT AddGeometryColumn( 'roads', 'roads_geom', -1, 'GEOMETRY', 3 );

A maioria das funções executadas pela biblioteca de GEOS confiam na suposição que suas geometrias são válidas como especificadas pela Especificação de Característica Simples de OpenGIS (OpenGIS Simple Feature Specification). Para verificar a validade das geometrias você pode usar a função IsValid():

gisdb=# select isvalid('LINESTRING(0 0, 1 1)'), isvalid('LINESTRING(0 0,0 0)');
 isvalid | isvalid
---------+---------
 t | f

Por default, PostGIS não aplica esta verificação de validade na entrada da geometria, porque testar a validade necessita lotes de tempo do processador central (CPU) para geometrias complexas, especialmente poligonos. Se não confiar em suas fontes de dados, pode manualmente reforçar tal verificação a suas tabelas, adicionando um confinamento da verificação:

ALTER TABLE mytable ADD CONSTRAINT geometry_valid_check CHECK (isvalid(the_geom));

Se você encontrasse quaisquer mensagens de erro estranhas como "GEOS Intersection() apresentou um erro!" ou "JTS Intersection() apresentou um erro!" quando chamar funções PostGIS com entrada de geometrias válidas, você provavelmente encontrou um erro em PostGIS ou em uma das bibliotecas de uso dele, e você deve contatar os colaboradores de PostGIS. O mesmo é verdadeiro se uma função de PostGIS retornar uma geometria inválida para a entrada válida.

BEGIN;
INSERT INTO ROADS_GEOM (ID,GEOM,NAME ) VALUES (1,GeomFromText('LINESTRING(191232 243118,191108 243242)',-1),'Jeff Rd');
INSERT INTO ROADS_GEOM (ID,GEOM,NAME ) VALUES (2,GeomFromText('LINESTRING(189141 244158,189265 244817)',-1),'Geordie Rd');
INSERT INTO ROADS_GEOM (ID,GEOM,NAME ) VALUES (3,GeomFromText('LINESTRING(192783 228138,192612 229814)',-1),'Paul St');
INSERT INTO ROADS_GEOM (ID,GEOM,NAME ) VALUES (4,GeomFromText('LINESTRING(189412 252431,189631 259122)',-1),'Graeme Ave');
INSERT INTO ROADS_GEOM (ID,GEOM,NAME ) VALUES (5,GeomFromText('LINESTRING(190131 224148,190871 228134)',-1),'Phil Tce');
INSERT INTO ROADS_GEOM (ID,GEOM,NAME ) VALUES (6,GeomFromText('LINESTRING(198231 263418,198213 268322)',-1),'Dave Cres');
COMMIT;

O arquivo de dados pode ser transportado facilmente para dentro do PostgreSQL usando o monitor de terminal SQL "psql":

psql -d [database] -f roads.sql

Note que - a, - c, - d e - p é mutuamente exclusivo.

Uma sessão de exemplo que usa o carregador para criar um arquivo e carregá-lo poderia ser como segue:

# shp2pgsql shaperoads myschema.roadstable > roads.sql
# psql -d roadsdb -f roads.sql

Podem ser feitos uma conversão e carga de tudo em um único comando, usando caminhos (pipes) como no UNIX:

# shp2pgsql shaperoads myschema.roadstable | psql -d roadsdb

Os meios mais diretos de extrair dados do banco de dados são usar um SQL, para selecionar dados e descarregar as colunas resultantes em um arquivo de texto:

db=# SELECT id, AsText(geom) AS geom, name FROM ROADS_GEOM;
id | geom | name
---+-----------------------------------------+-----------
 1 | LINESTRING(191232 243118,191108 243242) | Jeff Rd
 2 | LINESTRING(189141 244158,189265 244817) | Geordie Rd
 3 | LINESTRING(192783 228138,192612 229814) | Paul St
 4 | LINESTRING(189412 252431,189631 259122) | Graeme Ave
 5 | LINESTRING(190131 224148,190871 228134) | Phil Tce
 6 | LINESTRING(198231 263418,198213 268322) | Dave Cres
 7 | LINESTRING(218421 284121,224123 241231) | Chris Way
(6 rows)

Porém, haverá restrições que será necessário reduzir o número de campos devolvido. No caso de restrições atributos-baseados, usar exatamente a mesma sintaxe de SQL como normal com uma tabela não espacial. No caso de restrições espaciais, os operadores seguintes são habilitados/completos:

Logo, você pode usar estes operadores em questão. Note que ao especificar geometrias e caixas na linha de comando SQL, você tem que transformar as representações de string explicitamente em geometrias usando a função "GeometryFromText () ". Por exemplo:

SELECT
 ID, NAME
FROM ROADS_GEOM
WHERE
 GEOM ~= GeomFromText('LINESTRING(191232 243118,191108 243242)',-1);

A "query" anterior devolveria o único registro da tabela "ROADS_GEOM" pela qual a geometria era igual aquele valor.

Ao usar o operador "&& ", pode especificar um outro BOX3D como característica de comparação ou um GEOMETRY. Porém, quando você especifica um GEOMETRY que sua caixa delimitada será usada para a comparação.

SELECT
 ID, NAME
FROM ROADS_GEOM
WHERE
 GEOM && GeomFromText('POLYGON((191232 243117,191232 243119,191234 243117,191232 243117))',-1);

A "query" anterior usará a caixa delimitada do polígono para propósitos de comparação.

A "query" espacial mais comum provavelmente será uma query "frame-based", usada por cliente de software, como navegador de dados e mapas na web, pegar um valor de dados "map-frame" para exibição. Usando um objeto "BOX3D" para a visualização, como demonstrado como segue:

SELECT
 AsText(GEOM) AS GEOM
FROM ROADS_GEOM
WHERE
 GEOM && GeomFromText('BOX3D(191232 243117,191232 243119)'::box3d,-1);

Note que o uso do SRID, especifica a projeção do BOX3D. O valor -1 é usado para indicar nenhum SRID especificado.

O descarregador de tabela pgsql2shp conecta diretamente ao banco de dados e converte uma tabela em um arquivo Shape. A sintaxe básica é:

pgsql2shp [<options>] <database> [<schema>.]<table>

pgsql2shp [<options>] <database> <query>

As opções de linha de comando são:

GiST representa "Generalized Search Tree" e é uma forma generalizada de indexar. Além da da indexação de GIS, GiST é usada para acelerar buscas em todos os tipos de estruturas de dados irregulares (arranjos de números inteiros, dados espectrais, etc) que não são amenos a indexação normal B-Tree.

Uma vez que uma tabela de dados de GIS excede algumas mil linhas, você poderá construir um índice para buscas espaciais de dados (a menos que todas suas buscas estejam baseadas em atributos, pelo qual você queira construir um índice normal nos campos de atributo).

A sintaxe para construir um índice de GiST em uma coluna de geometria é como segue:

CREATE INDEX [indexname] ON [tablename]
 USING GIST ( [geometryfield] GIST_GEOMETRY_OPS ); 

Construindo um índice espacial é um exercício computacionalmente intensivo: em tabelas ao redor de 1 milhão de linhas, em uma máquina de 300MHz Solaris, achamos que com a construção de um índice GiST leva aproximadamente 1 hora. Depois de construir um índice, é importante forçar PostgreSQL a coletar estatísticas de tabela que são usadas para otimizar planos de "query":

VACUUM ANALYZE [table_name] [column_name];

-- This is only needed for PostgreSQL 7.4 installations and below
SELECT UPDATE_GEOMETRY_STATS([table_name], [column_name]);

Índices GiST têm duas vantagens em relação a índices R-Tree em PostgreSQL. Em primeiro lugar, índices GiST são "null safe" (segurança nula), significando que eles podem indexar colunas que incluem valores nulos. Em segundo lugar, indices GiST apóiam o conceito de "lossiness" que é importante quando lidado com objetos de GIS com páginas PostgreSQL de tamanhos maiores que 8K. "Lossiness" permite PostgreSQL armazenar somente a parte impor tante de um objeto em um índice - no caso de objetos de GIS, só a caixa de saltos. Objetos de GIS maiores que 8K causarão índices R-Tree para falhar no processo de ser construído.

Índices aceleram o acesso de dados: uma vez que o índice é construído, a transparência de planejamento de queries decide quando usar informação de índice para acelerar um plano de "query". Infelizmente, a "query" PostgreSQL não planeja otimizar bem o uso de índices de GiST, às vezes buscas que deveriam usar um índice espacial ao invés do padrão para uma busca sequencial da tabela inteira.

Se você acha que seus índices espaciais não estão sendo usados (ou seus índices de atributo, para aquele assunto) existe um agrupamento de coisas que você pode fazer:

Na construção de uma "query" é importante lembrarmos que os operadores baseados em saltos de caixa tal como &&, pode tirar proveito do índice espacial de GiST. Funções como distance () não pode usar o índice para otimizar suas operações. Por exemplo, a "query" seguinte seria bastante lenta em uma tabela grande:

SELECT the_geom FROM geom_table
WHERE distance( the_geom, GeomFromText( 'POINT(100000 200000)', -1 ) ) < 100

Esta "query" está selecionando todas as geometrias em geom_table que está dentro de 100 unidades do ponto (100000, 200000). Estará lento porque está calculando a distância entre cada ponto na tabela e nosso ponto especificado, ie. distance () calculados para cada linha na tabela. Podemos evitar isto usando o operador && para reduzir o número de cálculos de distância requerido:

SELECT the_geom FROM geom_table
WHERE the_geom && 'BOX3D(90900 190900, 100100 200100)'::box3d
 AND distance( the_geom, GeomFromText( 'POINT(100000 200000)', -1 ) ) < 100

Esta "query" seleciona as mesmas geometrias, mas faz isto de um modo mais eficiente. Supondo que existe um índice GiST em the_geom, o operador de "query" reconhecerá que pode usar o índice para reduzir o número de linhas antes de calcular o resultado da função distance ().
Note que a geometria de BOX3D que é usada dentro da operação && é uma caixa quadrada centrada no ponto original unidade 200 - esta é nossa "query box". O operador && usa o índice para reduzir rapidamente o resultado atribuído a essas geometrias, que têm salto de caixas que sobrepõem a "query box". Supondo que nossa "query box" é muito menor que as extensões da tabela de geometria inteira, isto reduzirá drasticamente o número de distância de cálculos que precisam ser feitos.

Os exemplos nesta seção utilizarão duas tabelas, uma tabela de estradas lineares, e uma tabela de limites poligonal da municipalidade. As definições de tabela para a tabela dos bc_roads são:

 Column | Type | Description
------------+-------------------+-------------------
 gid | integer | Unique ID
 name | character varying | Road Name
 the_geom | geometry | Location Geometry (Linestring)

A definição de tabela para a tabela do bc_municipality é:

 Column | Type | Description
-----------+-------------------+-------------------
 gid | integer | Unique ID
 code | integer | Unique ID
 name | character varying | City / Town Name
 the_geom | geometry | Location Geometry (Polygon)

postgis=# SELECT sum(length(the_geom))/1000 AS km_roads FROM bc_roads;
 km_roads
------------------
 70842.1243039643
(1 row)

postgis=# SELECT area(the_geom)/10000 AS hectares FROM bc_municipality
 WHERE name = 'SÃO PAULO'
------------------
 32657.9103824927
(1 row) 

postgis=# SELECT name, area(the_geom)/10000 AS hectares
 FROM bc_municipality
 ORDER BY hectares DESC
 LIMIT 1;
 name | hectares
---------------+-----------------
 TUMBLER RIDGE | 155020.02556131
(1 row)

postgis=# SELECT m.name, sum(length(r.the_geom))/1000 as roads_km
 FROM bc_roads AS r,bc_municipality AS m
 WHERE r.the_geom && m.the_geom
 AND contains(m.the_geom,r.the_geom)
 GROUP BY m.name
 ORDER BY roads_km;

 name | roads_km
----------------------------+------------------
 SURREY | 1539.47553551242
 VANCOUVER | 1450.33093486576
 LANGLEY DISTRICT | 833.793392535662
 BURNABY | 773.769091404338
 PRINCE GEORGE | 694.37554369147
 ...

postgis=# CREATE TABLE pg_roads as
 SELECT intersection(r.the_geom, m.the_geom) AS intersection_geom,
 length(r.the_geom) AS rd_orig_length,
 r.*
 FROM bc_roads AS r, bc_municipality AS m
 WHERE r.the_geom && m.the_geom
 AND intersects(r.the_geom, m.the_geom)
 AND m.name = 'SÃO PAULO';

postgis=# SELECT sum(length(r.the_geom))/1000 AS kilometers
 FROM bc_roads r, bc_municipality m
 WHERE r.the_geom && m.the_geom
 AND r.name = 'Avenida dos Autonomistas'
 AND m.name = 'OSASCO';
 kilometers
------------------
 4.89151904172838
(1 row)

postgis=# SELECT gid, name, area(the_geom) AS area
 FROM bc_municipality
 WHERE nrings(the_geom) > 1
 ORDER BY area DESC LIMIT 1;
 gid | name | area
-----+--------------+------------------
 12 | SPALLUMCHEEN | 257374619.430216
(1 row)

Usar PostGIS com Mapserver, você precisará conhecer como configurar o Mapserver que está além da extensão desta documentação. Esta seção cobrirá distribuição e detalhes de configuração de PostGIS específico.

Usar PostGIS com Mapserver, você precisará:

A cláusula USING pseudo-SQL é usada para acrescentar alguma informação para ajudar a entender os resultados mapserver de maior complexidade das queries. Mais especificamente, quando uma visão ou um subselect é usado como tabela fonte (a uso certo de "FROM" em uma definição de DATA) é mais difícil para mapserver que automaticamente determina um identifi- cador único para cada linha e também o SRID para a tabela. A cláusula USING pode proporcionar para mapserver estes dois tipos de informação como segue:

DATA "the_geom FROM (SELECT table1.the_geom AS the_geom, table1.oid AS oid, table2.data AS data
 FROM table1 LEFT JOIN table2 ON table1.id = table2.id) AS new_table USING UNIQUE oid USING SRID=-1"

LAYER
 CONNECTIONTYPE postgis
 NAME "roads"
 CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
 DATA "the_geom FROM roads"
 STATUS ON
 TYPE LINE
 CLASS
 COLOR 0 0 0
 END
END

Esta camada exibirá todas as geometrias de estrada na tabela de estradas com linhas pretas.

Agora dizemos que nós queremos mostrar só as rodovias até que nós conseguirmos fechar a câmara em pelo menos 1:100000 balança – as próximas duas camadas obterão este efeito:

LAYER
 CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
 DATA "the_geom FROM roads"
 MINSCALE 100000
 STATUS ON
 TYPE LINE
 FILTER "road_type = 'highway'"
 CLASS
 COLOR 0 0 0
 END
END

LAYER
 CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
 DATA "the_geom FROM roads"
 MAXSCALE 100000
 STATUS ON
 TYPE LINE
 CLASSITEM road_type
 CLASS
 EXPRESSION "highway"
 SIZE 2
 COLOR 255 0 0
 END
 CLASS
 COLOR 0 0 0
 END
END

A primeira camada é usada quando a balança é maior que 1:100000, e exibe só as estradas de tipo "highway" (rodovia) com linhas pretas. A opção FILTER causa só estradas de TIPO "highway" (rodovia) a ser exibida.

A segunda camada é usada quando a balança é menos que 1:100000, e exibirá rodovias como linhas vermelhas grossas, e outras estradas como linhas pretas regulares.

Assim, nós fizemos um par de coisas interessantes que usam só funcionalidade de mapserver, mas nossa declaração DATA SQL permaneceu simples. Suponha que o nome da estrada é armazenado em outra tabela (por qualquer razão) e nós precisamos fazer um una adquirir isto e etiquetar nossas estradas.

LAYER
 CONNECTION "user=theuser password=thepass dbname=thedb host=theserver"
 DATA "the_geom FROM (SELECT roads.oid AS oid, roads.the_geom AS the_geom, road_names.name as name
 FROM roads LEFT JOIN road_names ON roads.road_name_id = road_names.road_name_id) AS named_roads
 USING UNIQUE oid USING SRID=-1"
 MAXSCALE 20000
 STATUS ON
 TYPE ANNOTATION
 LABELITEM name
 CLASS
 LABEL
 ANGLE auto
 SIZE 8
 COLOR 0 192 0
 TYPE truetype
 FONT arial
 END
 END
END

Esta camada da anotação adiciona etiquetas verdes a todas as estradas quando a escala começa para baixo a 1:20000 ou menos. Demonstra também como usar um "join" SQL em uma definição DATA.

...

...