Tenho visto vários posts sobre o tema, mas até o momento não vi nenhum simplificando e resumindo o assunto. Aguardei por um tempo para ver se alguém traria algo novo ou um ponto de vista diferente sobre o assunto, mas acho que estamos todos no mesmo barco =).
Há um bom tempo percebi que de fato os parâmetros de transformação do QGIS entre os Data (plural de Datum) SAD69 <-> SIRGAS2000 <-> Córrego Alegre estão todos errados em comparação aos parâmetros oficiais do IBGE. Procurei saber como poderia solucionar esse problema, pois é um dos fatores que dificulta o uso maior do QGIS (software livre) em minha instituição, principalmente aos usuários comuns, que não precisam e/ou não tem interesse em ser especialistas em Geoprocessamento.
À medida que fui estudando e fuçando sobre o assunto, descobri que o problema não é único e exclusivamente do QGIS, mas sim da biblioteca .PROJ4, biblioteca essa que vários softwares (proprietários ou livres) utilizam como catálogo dos Sistemas de Referência de Coordenadas (SRC) e de parâmetros de transformação entre Data utilizados por todo o planeta. Sendo assim, abri um ticket no site do .PROJ4 reportando o problema, pois eles arrumando na fonte, as aplicações clientes seriam automaticamente corrigidas (QGIS, PostGIS, etc.).
Abaixo está o resumo do que escrevi no ticket reportado (http://trac.osgeo.org/proj/ticket/241 – Ticket #241 Rectify Brazil SAD69 to WGS84 transformation parameters)
Para transformação SAD69 para SIRGAS2000 (ou WGS84, que dá na mesma) exitem 4 opções:
- SAD69 Rede Clássica
- Usado para coordenadas obtidas com base em estações estabelecidas por meio das técnicas clássicas de posicionamento antes do ajustamento global da rede em 1996 (até 15/9/1996)
- Método: NTV2
- Parâmetros: arquivo SAD69_003.gsb (ProGriD)
- SAD69 1996 Rede Clássica
- Usado para coordenadas obtidas com base em estações estabelecidas por meio das técnicas clássicas de posicionamento após o ajustamento global da rede em 1996 (após 15/9/1996).
- Método: NTV2
- Parâmetros: arquivo SAD69_003.gsb (ProGriD)
- SAD69 1989
- Coordenadas obtidas com base em estações estabelecidas por meio das técnicas espaciais de posicionamento (estações Doppler ou GPS) ou através de receptores GPS entre 01/1/1987 e 01/1/1994.
- Método: Resolução do Presidente do IBGE nº 22, de 21 de julho de 1983. É a MOLODENSKII? Se alguém puder confirmar, agradeço =)
- Parâmetros:
- DX = -66,87
- DY = +4,37
- DZ = -38,52
- SAD69 2005
- Coordenadas obtidas com base em estações estabelecidas por meio das técnicas espaciais de posicionamento (estações Doppler ou GPS) ou através de receptores GNSS após 01/1/1994.
- Método: Resolução do Presidente do IBGE nº 01 de 25 de fevereiro de 2005 que remete à Resolução do Presidente do IBGE nº 22, de 21 de julho de 1983
- Parâmetros:
- DX = -67,35
- DY = +3,88
- DZ = -38,22
Hoje na biblioteca da .PROJ4 só tem 1 opção de transformação SAD69 para WGS84 (SIRGAS2000) e esta ainda está com os valores errados:
EPSG:4618
+proj=longlat +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 +no_defs
Diante desse “paranauê” todo, eu sugeri o seguinte para as transformações que utilizam 3 parâmetros (dx, dy, dz – técnicas espaciais). Em relação às transformações que utilizam NTv2, vi que o pessoal do QGIS já está trabalhando para importar os arquivos *.gsb:
SAD69 BRAZIL 1989 – EPSG: XXXX
+proj=longlat +ellps=aust_SA +towgs84=-66.87,4.37,-38.52,0,0,0,0 +no_defs
SAD69 BRAZIL 2005 – EPSG: XXXX
+proj=longlat +ellps=aust_SA +towgs84=-67.35,3.88,-38.22,0,0,0,0 +no_defs
Um erro comum dos usuários é pensar que a transformação SAD69/1996 é a mais correta simplesmente por ser a “mais recente”. Não existe transformação “mais correta”, existe apenas a pergunta: “Qual das opções se aplica às suas coordenadas em questão?” e a partir daí você saberá qual caminho seguir.
Peço ajuda à Comunidade de Usuários e Desenvolvedores do QGIS para que estes apoiem e, caso haja, aos que participam ativamente da comunidade da .PROJ4 para que discutam e implementem essas correções. Essas imprecisões na biblioteca .PROJ4 podem ter impactos relevantes no produto final. Embora essa imprecisão ocorra numa biblioteca que serve de referência também para softwares proprietários (ArcGIS), para o usuário final a culpa e a imagem negativa acaba recaindo sobre o software livre, dificultando sua popularização e crescimento saudável da comunidade colaborativa. E até explicar que a culpa não é exclusiva de software livre, além de ter de gastar energia com isso, é melhor corrigir logo na fonte que resolve o problema.
Caso haja alguma imprecisão na minha colocação, ou para qualquer outra dúvida, estou à disposição. =)
Luiz Paulo Beghelli Junior
Especialista em Recursos Minerais/Geólogo
Coordenação de Geoprocessamento – CGEO
Departamento Nacional de Produção Mineral – DNPM
Comments are closed