Terralib5 Docs

Date: Tue, 25 Aug 2009 17:34:40 -0300

From: lubia@dpi.inpe.br

Oi pessoal,

revendo as coisas de projeção e tentando dar um fim nisso, minhas sugestões são:

a) ter uma estrutura de parâmetros de projeção chamada TeSRSDescriptor que contém os parâmetros típicos de um sistema de referência espacial (TeDatumParams + TeProjectionParams da 3.3.1).

• sugiro que seja apenas uma estrutura (não tem necessidade de ser classe pois não é uma interface, nem vai ser derivada).
• essa estrutura terá as funções de exportação para os formatos WKT e até mesmo proj4 ou XML, ou códigos EPSG, ou alguma outra autoridade se for necessário.
• a instanciação pode ser feita manualmente (setando cada um dos parâmetros), a partir de códigos EPSG, ou o reverso do que mencionei no item anterior: a partir de um WKT, uma descrição proj4 ou um XML.
• pode ser um referência contada, pois como eu disse ela apenas é uma estrutura de parâmetros.

b) ter uma classe que é o transformador de coordenadas, que dado dois TeSRSDescriptor (from e to) converta, de uma simples coordenada a uma geometria TerraLib inteira.

• essa seria uma interface. As implementações concretas serão baseadas em bibliotecas (ex. proj4) ou mesmo códigos próprios da TerraLib quando for o caso.

Alguns casos de uso:

1) Importando um shapefile:

string wkt (read(file.prj)); // se for ler do .prj
 
TeSRSDecriptor srs(wkt);
 
TeSRSDescriptor srs();
 
srs.lat0 = ...               // se for vir da interface com o usuario
 
int srid = srs.srsID();  // para usar na sql de insercao no banco

2) Se for desenhar um dado do banco em um canvas com projeção diferente (como a velha Vista):

TeSRSDecriptor srsDado(polygon.getSRID());
 
TeSRSDescriptor srsCanvas(xml);//ou outra forma de instanciacao
 
TeSRSTransformer*  trans TeSRSTransformerFactory::make(srsDado,srcCanvas);
 
trans->transform(polygon, polygon2);  // ou
 
trans->transform(polygon.getBoxInternal(), box2); // ou
 
trans->transform(coord1,coord2); // e quantos forem convenientes.

Na verdade a mudança é pouca em relação ao que tínhamos antes. Basicamente o que tem a mais é um ID único por SRS e a fábrica de transformador, tem mais a ver com o suporte (qual biblioteca) que com diferentes projeções.

Para usar o conceito de ID único ele tem que ser mapeado para alguma coisa que faça sentido para quem vai realmente transformar (por ex. o postgis guarda o SRID MAIS a descrição proj4). Esses mapas podem ser lidos de arquivos de configuração ou podem estar descritos dentro das classes (como faz a OGR, tem um define pra cada um).

No momento tenho que achar também lugares pra por unidades. Que nunca levamos a sério antes. Tem que ter defines de unidades angulares e planas e o fator de conversão para graus decimais e metros. Sou a favor de defines também.

Enfim, tem muita coisa para implementar, mas quero saber se vocês querem alguma outra informação, vão dar alguma outra sugestão ou posso implementar. Pois não vale a pena perder tempo fazendo código pra depois jogar fora. Seguindo essas idéias faço reprojeção com proj4 rápido (eu acho). Mas se for pra ter que discutir mais ainda eu espero.

Lubia

Correndo o risco de parecer um pouco intrometido, gostaria de dizer que é sempre bom o ID ser o próprio código EPSG. Ele é um padrão informal que todos utilizam para buscar projeções. O usuário espera poder encontrar suas projeções através do EPSG (além da busca por nome). Portanto é natural pensar em utilizar uma tabela em banco (junto dos dados ou um para todo o aplicativo) para armazenar as projeções, que deveria ser alimentada pela lista da EPSG. A maioria dos softwares acaba por criar uma lista de projeções que fica dessincronizada com a lista da EPSG. Não vi solução ótima ainda para isso pois não acredito que exista nenhum serviço da EPSG para sincronia de listas.

Mauricio