Em tese, se o raster está armazenado no banco e conseguimos determinar o valor de cada pixel, poderíamos usar a SQL para realizar álgebra de mapas? A resposta é sim, podemos. É claro, já existem softwares especializados em realizar álgebra de mapas, como o IDRISI, ENVI, SPRING, ArcGIS (com Spatial Analyst), o módulo Sextante do gvSIG, WhiteBox, entre outros.

A vantagem de fazermos isto no PostGIS é que podemos aproveitar de algumas funcionalidades do banco de dados para realizar atualizações automáticas (funciona, mas a perfomance não deve ser das melhores), controlar melhor o acesso aos rasters - centralizando tudo em uma única localização, backup, etc.

Existem diversas funções para análise espacial de rasters, incluindo as matemáticas, lógicas, entre outras. Hoje irei mostrar apenas algumas matemáticas, que são bem simples. O módulo WKT Raster já planeja construir em C (linguagem nativa do PostgreSQL) algumas funções para análise espacial, mas enquanto isto não acontece, vamos levando com estas aqui.

Importante: estas funções só operam com rasters de uma única banda. Todas as operações são realizadas na banda 1. Nenhuma operação é realizada na banda 2 ou 3 - se bem que o suporte para tal é simples de ser construído.

Cuidado ao utilizar estas funções. Caso você sobreescreva seu raster, não o conseguirá de volta - caso precise.

ST_Plus

Esta função adiciona um valor double precision ao nosso raster de interesse. Se o pixel tem valor 1 e nosso argumento é 1, o resultado daquele pixel será 2. Esta função tem como entrada um raster e um valor numérico. O retorno da função é um objeto raster completo.

CREATE OR REPLACE FUNCTION ST_Plus(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			z1 := ST_Value(p_grid,i,j);
			grid := st_setvalue(grid,1,i,j,z1 + z);

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

A função é bem simples. Ela copia o raster original em memória e adiciona o valor à cada pixel. Sem segredos. Como usá-la? Recomendo primeiramente, duplicar sua coluna do tipo raster, pois a função de adição de colunas raster é bastante longa e com parâmetros meio obscuros. Procure o arquivo SQL gerado pelo gdal2wktraster e ache a linha que adiciona a coluna. Modifique o nome da coluna e execute este comando novamente. Depois disso popule a coluna com os novos valores.

SELECT AddRasterColumn('public','teste_raster','grid_stplus',-1, ARRAY['16BUI'], false,
       true, null, 0.000833, -0.000833, 9, 9,
           ST_Envelope(
               ST_SetSRID('POLYGON((-49.500416 -18.000416,-49.500416 -19.000416,-48.000416 -18.000416,-48.000416 -19.000416,-49.500416 -18.000416))'::geometry, -1)));

UPDATE teste_raster SET grid_stplus = ST_Plus('nome_da_coluna_raster_original',10);

Faça um teste com ST_Value para identificar se tudo correu bem. Neste teste, somamos 10 unidades ao valor de cada pixel da coluna original raster. Por que estamos criando uma coluna extra para armazenar nosso novo raster? Se alterarmos o raster original, não conseguiremos ele de volta, portanto, cuidado ao utilizar as funções.

ST_Minus

De forma similar à ST_Plus, ST_Minus vai subtrair determinado valor de cada pixel de nosso raster e nos trará como resultado o raster modificado.

CREATE OR REPLACE FUNCTION ST_Minus(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			z1 := ST_Value(p_grid,i,j);
			grid := st_setvalue(grid,1,i,j,z1 - z);

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

Recomendo testar da mesma maneira que a função anterior. O uso é o mesmo - modificando o nome da função.

ST_Plus

Esta função realiza a multiplicação do valor do pixel. Simples e direta.

CREATE OR REPLACE FUNCTION ST_Times(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			z1 := ST_Value(p_grid,i,j);
			grid := st_setvalue(grid,1,i,j,z1 * z);

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

Use-a do mesmo jeito que as anteriores.

ST_Divide

CREATE OR REPLACE FUNCTION ST_Divide(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN
	if (z = 0) then
		return p_grid;
	end if;

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			z1 := ST_Value(p_grid,i,j);
			grid := st_setvalue(grid,1,i,j,z1 / z);

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

ST_Power

Esta função eleva o valor da célula ao valor passado como parâmetro na função. Se temos uma célula de valor 2, e passamos 2 como parâmetro, teremos o 4 como resultado (2^2);

CREATE OR REPLACE FUNCTION ST_Power(p_grid raster, z double precision)
	RETURNS raster AS
$$
DECLARE
	w integer;
	h integer;
	z1 integer;

	grid raster;
BEGIN

	SELECT
		ST_Width(p_grid),
		ST_Height(p_grid)
	 into w,h;

	-- realizar cópia do raster original
	grid := p_grid;

	for i in 1..h loop
		for j in 1..w loop

			-- selecting cell value
			if z = 0 then
				grid := st_setvalue(grid,1,i,j,1);
			else
				z1 := st_value(p_grid,i,j);
				grid := st_setvalue(grid,1,i,j,z1 ^ z);
			end if;

		end loop;
	end loop;

	return grid;
END
$$
language 'plpgsql';

E assim podemos construir funções que alterem nossos rasters originais. São funções simples, praticamente demonstrativas. Na sequência demonstraremos algumas funções mais interessantes, como declividade, cálculo de fluxo de direção, identificação de depressões, eliminação de depressões, entre outras.

Um abraço,

George R. C. Silva

Related posts:

1. PostGIS WKT Raster
2. Funções PostGIS #2
3. Funções PostGIS #1

Agora vamos tecer algumas considerações sobre os padrões GML, KML e SLD.

Geographic Markup Language (GML)

O objetivo da GML é oferecer um conjunto de regras com as quais um usuário pode definir sua própria linguagem para descrever seus dados, assim utilização do padrão GML permite a interoperabilidade entre dados geográficos.  Definindo como será o armazenamento e transporte de informações geográficas, incluindo propriedades espaciais e não espaciais das entidades geográficas.

O GML é usado também em serviços WFS para trocar feições entre clientes e servidores, servindo, portanto como suporte ao serviço WFS.

Keyhole Markup Language (KML)

A linguagem XML (eXtensible Markup Language), como o próprio nome já diz, pode ser extendida  ou ampliada. O próprio padrão  KML da OGC é uma extensão de um XML utilizado pelo Google para tornar possível a visualização de dados geográficos nos seus famosos programas: Google Earth e Google Maps.

A estrutura do KML é baseado em tags como ocorre com arquivos HTML e XML comuns. Estas tags do KML tem os nomes e atributos usados para objetivos de exibição específicas. Em termos simples, notamos que o Google Earth e e o Google Maps funcionam pra os arquivos KML como como navegadores.

O KML depende de outros padrões para gerar a visualização de dados geográficos, pois na sintaxe do KML proveniente de um serviço de internet existe uma requisição WMS.

Hoje, o OGC e o Google trabalham em conjunto para aprimorar a implementação do KML, além de manter a comunidade informada das atualizações e avanços em seu projeto.

Styled Layer Descriptor (SLD)

A especificação SLD se refere à um arquivo XML que representa graficamente entidades geográficas (textos, pontos, objetos lineares ou polígonos.). Na linguagem SLD podem ser definidas regras que agrupam objetos em diferentes categorias e definindo para cada grupo um estilo diferente, por exemplo a simbologia de um WMS (estabelecer cores e rótulos) a partir de regras a serem definidas.

Programas de SIG, como o Udig, geram arquivos SLD de forma automática. Para executar este processo, basta adicionar uma camada WFS à uma visualização do Udig, fazer uma requisição ao servidor através de uma URL adequada e depois criar temas e rótulos de acordo com as necessidades da aplicação.

Enfim, esta foi uma breve consideração sobre alguns dos principais padrões da OGC (WMS, WFS, WCS, GML, KML e SLD). Espero que tenham gostado. Qualquer dúvida, entre em contato deixando um comentário.

Um Abraço e até a próxima postagem

--

Anderson Medeiros

Tecnólogo em Geoprocessamento

Consultor em Geotecnologias Livres

Related posts:

1. Padrões Open Geospatial Consortium – Parte 1
2. O Geoprocessamento e Suas Tecnologias – Parte 2
3. Metadata #3

Olá Pessoal!

Hoje vou abordar um tema de extremo interesse para quem trabalha com Geotecnologias, livres ou não: Os padrões do Open Geospatial Consortium (OGC). Nesta primeira parte da série vamos entender o que é o OGC e os padrões WMS, WFS e WCS.

O Open Geospatial Consortium (OGC)

Desde seus primórdios em 1994 a instituição, que se chamava OpenGis Consortium, tem o com o objetivo de criar especificações de interfaces e padrões de intercâmbio de dados geoespaciais.

O OGC é hoje uma entidade internacional com mais de 350 companhias, agências governamentais e universidades, que tem o intuito de promover o desenvolvimento de tecnologias que facilitem a interoperabilidade entre diferentes sistemas que trabalhem com informação e  localização espacial.

Asim, o OGC define especificações, ou padrões (como o WMS, WFS, WCS, etc) aos quais produtos e serviços precisam se adequar para que a interação entre diversas fontes de dados e informações espaciais seja facilitada, independente de fatores como a plataforma utilizada. A partir de agora vamos começar a compreender três das especificações do OGC.

Web Map Service (WMS)

O padrão WMS define um serviço para a produção de mapas que serão apenas uma representação visual dos dados espaciais e não os dados em si. Estas representações serão geradas no formato de imagem, como JPEG, PNG e GIF ou em formato vetorial, como o Scalable Vector Graphics (SVG).

Este padrão especifica como o cliente deve requisitar as informações para o servidor e como este deve responder ao cliente. As operações WMS podem ser realizadas a partir de um navegador comum que fará a submissão das requisições sob a forma de uma URL.

É importante destacarmos que o conteúdo da URL dependerá da operação solicitada. Em outras palavras, através da URL, indica-se qual a informação que deve ser exibida (região geográfica e dado de interesse), bem como o sistema de referência espacial, além das características da imagem de saída (altura e largura).

Web Feature Service (WFS) e Web Coverage Service (WCS)

A especificação de serviço WFS define um serviço para que clientes possam recuperar feições especiais em formato GML (você terá mais detalhes sobre GML na segunda parte desta série sobre o OGC).  O WFS pode ser implementado pelo servidor em duas versões:

• Básica - Neste caso, basicamente funções de consulta ficam disponíveis, ou

• Transacional - Implementa o serviço completo, incluindo operações de inserção, deleção, edição e, claro, consulta à objetos espaciais.

Assim, podemos afirmar que o WFS apresenta maior interatividade que o WMS, pois este primeiro possibilita não apenas a visualização das feições geográficas, mas também sua manipulação.

Já o padrão WCS define o acesso aos dados que representam fenômenos com variação contínua no espaço. Este serviço é especificado para
tratamento de dados modelados como geocampos.

Breves Comparações entre WMS, WFS e WCS

Uma diferença marcante entre o WMS e o WCS é que este último retorna ao usuário dados sobre a semântica original dos fenômenos representados, ao invés de imagens. Em outras palavras, o WCS fornece os dados disponíveis de imagens, juntamente com detalhes descritivos sobre as mesmas, como a grade.

Já em uma comparação entre o WFS e o WCS notamos que o primeiro retorna os chamados geo-objetos, já no caso do WCS retorna geocampos, conforme mencionado anteriormente.

Assim, chegamos a conclusão de que o serviço WCS pode ser utilizada para enquadrar aplicações do Sensoriamento Remoto (pois em geral o SR está relacionado com geocampos) no contexto da interoperabilidade.

Conclusão e o que vem por ai

Dessa nossa breve análise sobre estes três dos diversos padrões do OGC podemos notar que cada um terá sua aplicabilidade, sendo interpretado e explorado de maneira diferente dependendo dos objetivos de seu projeto.

Programas como o gvSIG e o Udig permitem interações com webservices que sigam as especificações WMS, WFS e WCS.

Na segunda parte desse post veremos mais sobre as padrões da OGC, com ênfase nas especificações GML, SLD e KML.

Fiquem na expectativa...

--

Anderson Maciel Lima de Medeiros

Tecnólogo em Geoprocessamento

Related posts:

1. Padrões Open Geospatial Consortium – Parte 2
2. O Geoprocessamento e Suas Tecnologias – Parte 2
3. Monografias Geoprocessamento – IFPB

Conforme vimos na primeira parte deste post, o Geoprocessamento é um conjunto de tecnologias dinâmicas com alto potencial de aplicação.

Até aqui vimos que Geoprocessamento e SIG não são as mesma coisa. O SIG é apenas uma importante tecnologia dentre as diversas incluídas no Geoprocessamento.

Vimos também que programas como o gvSIG e ArcGis não são "SIGs" mas softwares para SIG. Assim como o Geoprocessamento possui várias ramificações tecnológicas o SIG é um sistema composto por softwares, hardwares, metodologias, recursos humanos e dados.

Ficamos de ver o que são e pra servem tecnologias como o Banco de Dados Geográfico e o WebMapping.

Banco de Dados Geográficos

Bom, vamos por partes. O que é um Banco de Dados (BD)?

Todo local, físico ou virtual onde estão armazenados dados, pode em certo sentido, ser chamado de banco de dados. Por exemplo, uma enciclopédia pode ser considerada um banco de dados. Mas para nós aqui da área de Geoprocessamento é mais importante o conceito especial de banco ou base de dados relacional. Ou seja um banco onde dados são armazenados na forma de tabelas relacionáveis entre si através campos chaves.

As mais diversas facetas de atividades, desde locadoras de DVD até grandes indústrias metalúrgicas usam-se deste tipo de base para ter um maior controle sobre fatores como cadastro de clientes e sua condição em relação à empresa (Inadimplência, por exemplo).

Neste ponto, é importante evitar confundir o BD em sí (conjunto de tabelas relacionáveis) com o programa que o gerenciará, o Sistema Gerenciador de Banco de Dados (SGBD). EM outras palavras, softwares como Access, MySQL, Oracle, PostgreSQL não são BD, mas sim SGBD.

Mas ainda não falamos no assunto deste tópico. O que é e para que serve um Banco de Dados Geográfico (BDG)?

O BDG, também chamado de Banco de Dados Espacial (BDE), é semelhante ao descrito acima (relacional), com a grande e importante diferença de suportar feições geométricas em suas tabelas.

Este tipo de base com geometria oferece a possibilidade de análise e consultas espaciais. É possível calcular nestes casos, por exemplo, áreas, distâncias e centróides, além de realizar a geração de buffers e outras operações entre as geometrias.

Como dica de estudos para você obter uma boa base conceitual sobre BDG, indico o livro "Banco de Dados Geográficos" do INPE, que está disponível para download em PDF aqui.

Atualmente, alguns programas de SGBD desenvolveram extensões que inserem no software características de Sistemas Gerenciadores de Banco de Dados Geográficos (SGBDG) o PostgreSQL, MySQL, e Oracle, sendo os dois primeiros softwares livres e o último proprietário.

Vamos falar um pouco mais do PostgreSQL e como ele passa a agir como SGBDG. O PostgreSQL é desenvolvido atualmente pela PostgreSQL Global Development Group. Quando se percebeu a necessidade de extender este SBGD para suportar dados espaciais desenvolveu-se a extensão conhecida como PostGis.

Sendo assim, vamos entender que o PostGis não é um BDG ou um SGBDG, ele é apenas uma extensão, um plugin, do PostgreSQL que lhe confere funções para armazenamento e manipulação de dados geográficos.

A figura abaixo procura mostrar a diferença entre o PostgreSQL e "seu filho". Note que para termos um BDG no PostgreSQL faz-se necessária a devida instalação da extensão PostGis.

Você pode importar arquivos vetoriais shapefile (*.shp) para dentro de um "Banco PostGis" utilizando recursos oferecidos pelo próprio programa ou utilizando algum software de SIG com essa funcionalidade. O shapefile será convertido em uma tabela espacial que pode ser integrada com as convencionais contidas na base, além de poder ser visualizada e manipulada através de programas como o gvSIG, Kosmo, Quantum Gis, Udig e muitos outros desta safra. Para baixar tutoriais sobre como realizar esta operação com alguns destes softwares, clique aqui.

Para baixar a versão mais recente do PostgreSQL e sua extensão espacial PostGis, acesse os links abaixo.

• PostgreSQL
• PostGis

Para finalizar este post vamos considerar outra tecnologia do Geoprocessamento, a saber, WebMapping.

WebMapping (WebGis)

A internet vem se destacando nos últimos anos como uma excelente ferramenta para disponibilização e interligação de dados das mais diversas fontes e naturezas.

A geomática, como área do conhecimento, também encontrou na internet um nicho para suas atividades. A disponibilização de mapas digitais, os chamados WebGis ou WebMapping, tem-se tornado comum, permitindo que um maior número de usuários tenha acesso a dados espacializados, de forma hábil e atraente.

Talvez o estopim para o crescimento das aplicações SIG para internet tenha sido a popularização de serviços online gratuitos de localização como o Google Earth e Google Maps.

Os mapas na web se apresentam de três formas princiapais:

1) Mapas Estáticos - Mapas no formato de imagem (*.jpg, *.gif, *.png, etc) integrados à páginas da internet.

2) Mapas Gerados à partir de formulários - Fornece-se parâmetros para geração de mapas na forma de imagem.

3) Mapas Dinâmicos - O usuário seleciona uma área de seu interesse em um mapa geral, gerando uma navegação para outro mapa ou imagem mais específico com informações mais detalhadas desta região. Em geral apresentam interface atraente com ícones para consulta espacial calculo de distância e etc.

Para mais detalhes sobre tipos de mapas veja a publicação disponibilizada neste link.

Há muitos softwares e frameworks livres para o desenvolvimento de aplicações WebGis. Podemos destacar alguns: MapServer, GeoServer, i3Geo, Alov Map, Time Map, Open Layers e P.Mapper.

Diversos órgãos públicos fazem uso destas ferramentas para divulgação dos resultados de seus trabalhos.

A imagem abaixo mostra um exemplo de aplicação desenvolvida com MapServer e o framework P.Mapper. Clique aqui para acessar a página da aplicação (Este é um exemplo de mapa dinâmico).

Nesta visão geral sobre algumas das tecnologias do Geoprocessamento, pudemos dissipar alguns falsos conceitos em torno de termos como SIG, BDG, SGBDG, WebGis, etc. Espero que tenham gostado do que leram.

Fiquem à vontade para deixar sua sugestão de tema, críticas e impressões através do e-mail anderson[@]geoprocessamento.net

Anderson Medeiros

Tecnólogo em Geoprocessamento

Related posts:

1. O Geoprocessamento e Suas Tecnologias – Parte 1
2. Agricultura Familiar e Geoprocessamento
3. Monografias Geoprocessamento – IFPB

Estava trabalhando em alguns assuntos no Sql Server 2008 e até aí tudo bem. Tinha alguns dados em outro banco de dados, representativos de pontos. Tudo UTM SAD69. O banco do GIS em Lat/Long SAD69.

As tabelas eram mais ou menos assim:

CREATE TABLE foo
(
id SERIAL NOT NULL,
x DOUBLE PRECISION NOT NULL,
y DOUBLE PRECISION NOT NULL,
z DOUBLE PRECISION NOT NULL,
sistema_coordenada VARCHAR(20) NOT NULL,0
 -- etc
);

Sempre com diversos pontos e diversos sistemas de coordenadas.
Bem, a idéia era montar uma visão no banco de dados, registar a parada com o ArcSDE, e disponibilizar os dados que eu queria em tempo real para os usuários do GIS, inclusive eu.

Liguei em uma certa empresa que comercializa um certo software, no suporte. Expliquei a situação, perguntei se o rapaz ou alguém lá saberia de uma solução para realizar o idealizado. De forma alguma (eu) estava viajando na maionese, pela minha experiência (que não é muita) com o PostGIS, sabia que era fazível.

O certo indivíduo que me atendeu, deve ter feito uma cara do outro lado de "What the hell?" sugeriu que eu jogasse minha tabela no ArcMap e rodasse um XY para plotar os dados. Valeu pela super dica amigão. Se você ler isto e lembrar de mim sabe que existe uma forma!

Mas vamos lá. O PostGIS, que é um tanto mais avançado que o Sql Server 2008 nesses quesitos, bastaria o seguinte para criar uma visão espacial (com um ponto de verdade, e não um par de coordenadas) e transformar a parada para o datum que eu queria:

CREATE OR REPLACE VIEW view_foo AS
    SELECT ST_Transform(ST_Point(X,Y),4618), coluna1, coluna2 from foo;

Bem, simples né? Acontece que o SQL Server 2008 NÃO POSSUI funções nativas para conversão de coordenadas/projeção de um sistema para outro.

Um camarada do trabalho, Danilo, me falou que já havia visto no CodePlex, um site com um repositório de código da Microsoft, um projeto que realizava o serviço. Bem, o projeto, Sql Spatial Tools, tem muita utilidade e outras funções, como agregador de geometrias, mas as funções de conversão de coordenadas estava furada. Pelo menos a que nós precisávamos usar.

Lembrei que o PostGIS, que também não tem esta capacidade nativa, mas é fornecida pela Proj4, e talvez poderíamos utilizar a Proj4. Mais uma busca no Codeplex e achamos a ProjNET, uma adaptação da Proj4 (acho que é escrita em C) para .NET, em C#.

Utilizamos o modelo da Sql Spatial Tools para registrar bibliotecas externas (muito top, parabéns Sql Server, muito tetinha de fazer) e para expor uma única função que criamos para o Sql Server. A ProjNET, ao contrário da Sql Spatial Tools, realmente converte as coordenadas.

Dicas

• Sempre olhe no Codeplex.
• Para registrar uma dll externa (dentro do Sql Server) utilize (isto é código SQL): CREATE ASSEMBLY ProjNet 'caminhoParaDll'
• Para registrar uma função: CREATE FUNCTION nomeFuncao (parametros) returns tipoRetorno AS external ProjNet.Namespace.Funcao
  É só.

No final nossa idéia ficou similar a do PostGIS, and it works. Resultado: utilizamos os dados que temos, sem a necessidade de administrar/atualizar FeatureClasses e realizar tarefas tediosas de Add XY data-Project Data e propensas à erros. E o melhor de tudo, é tudo em tempo real. Se o outro sistema for atualizado às 10:01:01:0001, nós iremos ver os dados atualizados às 10:01:01:0002.

Lições aprendidas

• Novamente, sempre olhe no CodePlex.
• É muito fácil desenvolver/linkar APIs e outros frameworks ao Sql Server 2008.
• Nunca, nunca confie no suporte técnico oferecido.

Thank you notes/Agradecimentos
Danilão! Pelo tempo gasto nisso e paciência.
Onald McDonald e Ogerio McDonald, pela torcida.
Ed Katibah, lead developer at Microsoft, who exchanged several emails with me and noticed that their implementation of Sql Spatial Tools is not correct (for UTM projections), and opened a ticket for fixing. Soon Sql Spatial Tools will be ready to handle all conversions.

Related posts:

1. History Tables – pt 1
2. Construindo funcionalidades para o WKT Raster
3. Contribuindo um pouquinho…

Alguns dias atrás me cadastrei no trac da OsGeo para ver se conseguia solucionar algum tiquete em aberto.

Para quem não sabe, trac é um sistema que controla as informações sobre bugs, melhoramentos entre outras coisas à fazer, dentro de um projeto de software. Ele permite um usuário aceitar uma tarefa, postar arquivos e mensagens e receber comentários em seu trabalho.

Aceitei o tíquete #180 que pede a criação de algumas funções para criar tabelas "históricas", permitindo o usuário saber quem alterou a tabela, como alterou, quando e todas as alterações feitas. À partir daí ele tem opções de restaurar uma feição que foi deletada ou editada de forma errada, entre outras coisinhas.

Montei algumas funções em pl/pgsql puro para gerar estes códigos, e as mesma estão disponíveis no link mostrado acima. Ainda existe muita discussão à ser feita para que elas comecem a pertencer ao código "oficial" do PostGIS, mas está caminhando. PS do dia 13/01/2010 - o patch foi aceito e já foi comitado em trunk. Provavelmente seu PostGIS já vem com o módulo, com algumas mudanças. Não deixe de conferir!

O bacana, além de aprender e conhecer gente nova, é poder devolver um pouco pra um software excelente. Uma contribuição pequena, com certeza, mas que mais pra frente pode ajudar muita gente.

George Silva

Related posts:

1. Monografia
2. Sql Server 2008 e o sistema de uma projeção só
3. Construindo funcionalidades para o WKT Raster