QGIS & Transformação de Datum (parâmetros oficiais) - Diagnóstico

[Luiz Paulo]

Bom dia. 

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 a quem conheça os desenvolvedores do QGIS no Brasil 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. =)

Beghelli Jr.

[Leônidas Descovi Filho]

Olá Luiz Paulo

Muito bem explicado o problema que voce constatou nos Sistemas de Referência do proj4.

Espero que fomente possíveis correções de problemas junto a biblioteca do proj4.

Abs

Leônidas

--
Comunidade QGIS Brasil: http://qgisbrasil.wordpress.com
---
Você recebeu essa mensagem porque está inscrito no grupo "qgisbrasil" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para qgisbrasil+...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para qgisb...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/qgisbrasil.
Para mais opções, acesse https://groups.google.com/d/optout.

[Sidney - Geosaber]

Luiz Paulo,

Parabéns pela explicação, realmente as pessoas fazem uma enorme confusão sobre a questão dos Sistemas de Referência de Coordenadas - SRC.

Sistemas de Coordenadas (Posicionamento e Localização) são dois: Geográficas (ou Geodésicas) e Planas (Projetadas).

Já Sistema de Referência de Coordenadas é o Datum usado no momento do Levantamento ou aquisição das informações que estão sendo mapeadas.

Isso tem implicação em todos os projetos de mapeamento e por consequência, a não conformidade com a Resolução 89.817/1984 que estabelece as Normas Técnicas da Cartografia Nacional. http://www.concar.ibge.gov.br/documentos.aspx?tipo=1

A solução que eu tenho indicado nas aulas do meu Curso presencial do QGIS é a seguinte:

Entrar em Configurações > SRC Personalizado e então clicar em Copiar SRC existente.

Então modificar os Parâmetros de Transformação, como você mostrou, com os valores de DX, DY e DZ fornecidos pelo IBGE para cada Datum (os parâmetros são diferentes em cada Realização do Datum).

Salvar e usar esse SRC Personalizado (corrigido) nos Projetos de Mapas.

Leônidas, acho que isso caberia como uma postagem no blog do site QGIS Brasil, o que acha?

Luiz Paulo, se der a permissão, eu escreve sua publicação lá, de forma que fique mais aberta à todos os Usuários do QGIS no Brasil.

Boa sorte.

Sidney Goveia

http://www.geosaber.com.br

[Sidney - Geosaber]

ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/nota_tecnica_termino_periodo_transicao_sirgas2000.pdf

[Leônidas Descovi Filho]

Car@s,

Fica a disposição toda e qualquer postagem de assunto de tamanho interesse no site qgis brasil.

Sidney, voce poderia explicar com exemplos esta criação de SRC personalizado no QGIS e postar no Site do qgis brasil?

Voce já está cadastrado como autor?

O Mesmo vale para o Luiz Paulo, fique a vontade em escrever breve esclarecimento nos moldes desta sua mensagem. Se tiveres interesse providenciamos um convite para autor no site do qgisbrasil.

Estende-se esse convite aos demais listeir@s que tenham intenção de escrever sobre relevantes assuntos ou criar tutoriais relacionados ao uso do qgis e seu ferramental.

Abs

Leônidas

Em 25 de fevereiro de 2015 16:36, Sidney - Geosaber <sidney...@gmail.com> escreveu:

ftp://geoftp.ibge.gov.br/documentos/geodesia/pdf/nota_tecnica_termino_periodo_transicao_sirgas2000.pdf

[Luiz Paulo]

Sidney, 

Permito sim que seja publicado =). Mas peço, por favor, que faça a referência, pois este foi um estudo que ninguém me ajudou e foi bem trabalhoso. Tive que me virar atrás de documentos, publicações científicas e informações totalmente espalhadas e fragmentadas para que pudesse entender o que estava acontecendo. E tudo isso tive de desenvolver no meu trabalho (ambiente e horário de trabalho), pois essas inconsistências impactavam em uma outra atividade que estava em curso. E o intuito de postar nesse fórum foi justamente de divulgar para a comunidade, para que outros não tenham que sofrer sozinhos até entender o que acontece (hehe). 

Também agradeço sua oferta, pois é mais uma forma de dar publicidade e trazer mais pessoas para apoiar a mudança, demonstrando aos desenvolvedores de GIS que existe essa demanda no Brasil.

Particularmente eu uso o SRC Personalizado, mas...é muito quebra-galho. São parâmetros que já devem vir no núcleo de qualquer aplicação que rode no Brasil.

Luiz Paulo Beghelli Junior

Especialista em Recursos Minerais/Geólogo

Coordenação de Geoprocessamento - CGEO

Departamento Nacional de Produção Mineral - DNPM

Obrigado, Sidney!

Beghelli Jr.

[Sidney - Geosaber]

Como o IBGE publicou hoje uma Nota Técnica sobre o fim da coexistência dos outros Sistemas de Referência, sendo agora somente o SIRGAS 2000 o Datum Planimétrico oficial no Brasil eu acabei criando uma postagem sobre isso e sobre os Parâmetros de Transformação no QGIS e publiquei no meu Blog e no Grupo do QGIS no Facebook.

Vou escrever ele no blog do QGIS Brasil para ficar de referência.

Até mais.

Sidney Goveia

http://www.geosaber.com.br

[Leônidas Descovi Filho]

Obrigado Sidney

Valeu

Abs

Leônidas

--

[Luiz Paulo]

Pois é...essa nota técnica chegou com 10 anos de atraso. Muitos usuários e especialistas tiveram dificuldade pra agrupar as publicações técnicas espalhadas do IBGE e consolidar num entendimento só. Não basta ser apenas o detentor da informação, se ela não é transmitida. E não apenas transmitida, mas repassada de forma esclarecida e didática. Falo isso porque infelizmente já vi vários casos em que os usuários não se atentaram para o fato da área de cobertura de cada transformação. Beleza, ok, isso está no manual do ProGriD, mas isso se o cara baixar o ProGriD. A partir do momento que eles fazem os mapas com o polígono das áreas de extensão, isso atrai muito mais atenção e facilita a propagação do conhecimento. E de forma muito mais rápida e eficaz. 

Por isso valorizo aqueles Professores esforçados e didáticos. Os caras fazem uma sociedade inteira uns ganhar 5 anos de vida! =D

E mesmo que o IBGE tenha publicado, ainda existirá por um longo tempo os dados de legado, aqueles que ainda dependerão desses parâmetros para serem transformados.

[Sidney - Geosaber]

Concordo com você, Luiz Paulo.

É preciso garimpar muito para conseguir informações precisas nessa área, mesmo as Normas Técnicas ficam ocultas em link perdidos nos sites oficiais.

Eu publiquei seu artigo no http://qgisbrasil.org/blog exatamente como você postou aqui.

Se tiver algum erro, por favor me avise para que eu possa arrumar.

Sidney Goveia

http://www.geosaber.com.br

[yjmenezes]

Luiz Paulo,

Boa tarde.

Muito bom o seu post. eu venho batendo em cima deste tema aqui na lista QGIS desde 2011.

Eu ja postei sobre a necessidade de correcoes nos arquivos da ESPG nas listas do SpatiaLite onde participa o Alexander Bruy, desenvolvedor do QGIS.

https://groups.google.com/d/msg/qgisbrasil/0AJ8ikANYKU/CiHQLYGJ01MJ

TODOS, sejam softwares Privativos ou OpenSource usam as definicoes do EPSG, portando ao contrario do que muitos podem pensar, o problema nao esta no QGIS ou GDAL/OGR ou PROJ4.
Em minha opniao, a correcao deve ser feita junto ao http://www.epsg.org/  ( os petroleiros ).

A babel dos SRID vai alem dos tres SAD69, e como voce relatou muito adequadamente, nao eh questao de se usar parametros mais novos e sim usar os parametros adequados a epoca dos dados  a serem transformados.

Fico satisfeito em ver que o assunto agora esta merecendo a devida atencao.

[]s
julio menezes
cartognu.org

[Pedro Venâncio]

Bom dia,

Aqui em Portugal também existe muita confusão em torno desse tema, por isso criamos (Grupo de Utilizadores QGIS Portugal) este post no nosso site:

http://qgis.pt/blog/2014/07/13/transformacao-de-coordenadas-e-utilizacao-das-grelhas-ntv2-no-qgis/

que tenta explicar como as coisas funcionam no QGIS.

Mais tarde, para facilitar a vida ainda mais aos utilizadores menos experientes, criamos um plugin para fazer as transformações dos data antigos para o PT-TM06/ETRS89, que é o sistema de referência em vigor aqui em Portugal:

http://qgis.pt/plugins.html

Espero que essa informação seja útil!

Abraço!

Pedro Venâncio

[Leônidas Descovi Filho]

Prezado Pedro

Muito didático o seu artigo, estas de Parabéns. Colabora em muito para um entendimento dos SRC em geral e no QGIS em particular.

Abraços

Leônidas

[Luiz Paulo]

Bom dia, pessoal. 

Obrigado pelas considerações =). O mais interessante é justamente isso: tem tanta gente que está passando pela mesma situação. Não estamos sozinhos!  

 

Bom dia,

Aqui em Portugal também existe muita confusão em torno desse tema, por isso criamos (Grupo de Utilizadores QGIS Portugal) este post no nosso site:

http://qgis.pt/blog/2014/07/13/transformacao-de-coordenadas-e-utilizacao-das-grelhas-ntv2-no-qgis/ 

que tenta explicar como as coisas funcionam no QGIS. 

Mais tarde, para facilitar a vida ainda mais aos utilizadores menos experientes, criamos um plugin para fazer as transformações dos data antigos para o PT-TM06/ETRS89, que é o sistema de referência em vigor aqui em Portugal:

http://qgis.pt/plugins.html 

Espero que essa informação seja útil!

Abraço!

Pedro Venâncio

Pedro, parabéns pelo site! Inclusive, o teu site foi um dos que li quando estava estudando e realmente me ajudou bastante =). Já tinha favoritado ele aqui pra poder usar como referência na hora de adaptar aos Data brasileiros. Vi a solução do plugin, que ajuda bastante e é uma ótima solução à curto prazo. Mas em paralelo podemos ir trabalhando e convencendo para que façam a modificação no core da biblioteca.

TODOS, sejam softwares Privativos ou OpenSource usam as definicoes do EPSG, portando ao contrario do que muitos podem pensar, o problema nao esta no QGIS ou GDAL/OGR ou PROJ4.
Em minha opniao, a correcao deve ser feita junto ao http://www.epsg.org/  ( os petroleiros ).

Julio, pior que segui justamente esse caminho de oreia seca. Achava que era QGIS, depois GDAL/OGR e fuçando neste, percebi que podia ser .PROJ4. Apesar de conhecer a EPSG, não tentei algo por lá porque já achei algo muito distante pra mim! (hahaha). Preciso de mais orientações de como proceder por lá.

O Mesmo vale para o Luiz Paulo, fique a vontade em escrever breve esclarecimento nos moldes desta sua mensagem. Se tiveres interesse providenciamos um convite para autor no site do qgisbrasil.

Leônidas, obrigado pela oferta! =D Atualmente estou bastante envolvido com alguns projetos aqui no trabalho, inclusive com a transformação do nosso banco espacial para sirgas2000. Mas tenho vontade sim de aos poucos aderir à comunidade GIS de software livre e ajudar no que for possível. =) Inclusão digital E espacial (hahaha).

Sidney, obrigado pela ajuda! =D Garimpar? Bixo, ta aí uma coisa que o fato de ser Geólogo me ajudou nesse processo =P. Cabrón, hoje de manhã me toquei de um vacilo: a nomenclatura do arquivo NTV2 da transformação SAD69/1996 está errada. Sim, usei ctrl+c e ctrl+v e esqueci de corrigir. Até tinha colocado em negrito, mas acabou passando. É só corrigir de:

• 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) para SAD96_003.gsb

Abraços

Beghelli Jr.

[Jorge Santos]

Brilhante explicação, Luiz!

O SAD 1969 de 1996 com seus parâmetros já consta na biblioteca de códigos EPSG do QGIS, apesar do Fuso 22 S desse SAD69 apresentar os parâmetros incorretos. A dica seria pedir para os desenvolvedores incluirem os demais.

​

Jorge Santos
Técnico em Geoprocessamento
http://www.processamentodigital.com.br/

Skype: jorgepsantos2002
Twitter: http://twitter.com/jpsantos2002
Facebook: http://www.facebook.com/ProcessamentoDigital

--

[yjmenezes]

Luiz Paulo / All

<<<<
Em quinta-feira, 26 de fevereiro de 2015 11:58:48 UTC-3, Luiz Paulo escreveu:

Bom dia, pessoal. 

Obrigado pelas considerações =). O mais interessante é justamente isso: tem tanta gente que está passando pela mesma situação. Não estamos sozinhos!  

 

Bom dia,

Aqui em Portugal também existe muita confusão em torno desse tema, por isso criamos (Grupo de Utilizadores QGIS Portugal) este post no nosso site:

http://qgis.pt/blog/2014/07/13/transformacao-de-coordenadas-e-utilizacao-das-grelhas-ntv2-no-qgis/ 

que tenta explicar como as coisas funcionam no QGIS. 

Mais tarde, para facilitar a vida ainda mais aos utilizadores menos experientes, criamos um plugin para fazer as transformações dos data antigos para o PT-TM06/ETRS89, que é o sistema de referência em vigor aqui em Portugal:

http://qgis.pt/plugins.html 

Espero que essa informação seja útil!

Abraço!

Pedro Venâncio

Pedro, parabéns pelo site! Inclusive, o teu site foi um dos que li quando estava estudando e realmente me ajudou bastante =). Já tinha favoritado ele aqui pra poder usar como referência na hora de adaptar aos Data brasileiros. Vi a solução do plugin, que ajuda bastante e é uma ótima solução à curto prazo. Mas em paralelo podemos ir trabalhando e convencendo para que façam a modificação no core da biblioteca.

TODOS, sejam softwares Privativos ou OpenSource usam as definicoes do EPSG, portando ao contrario do que muitos podem pensar, o problema nao esta no QGIS ou GDAL/OGR ou PROJ4.
Em minha opniao, a correcao deve ser feita junto ao http://www.epsg.org/  ( os petroleiros ).

Julio, pior que segui justamente esse caminho de oreia seca. Achava que era QGIS, depois GDAL/OGR e fuçando neste, percebi que podia ser .PROJ4. Apesar de conhecer a EPSG, não tentei algo por lá porque já achei algo muito distante pra mim! (hahaha). Preciso de mais orientações de como proceder por lá.

>>>>

So reforcando o que eu havia dito sobre as correcoes serem feitas na raiz ou seja no EPSG:
referencias:
Blog do Frank Warmerdam, ( aka FW ),  ja velho conhecido de todos (gdal/ogr) e atual mantenedor do PROJ4.  ( thx Frank ).
http://fwarmerdam.blogspot.com.br/2010/03/in-last-few-weeks-i-believe-i-have-made.html

Se o EPSG estiver errado os problemas vao continuar. Minha opiniao eh que tem de se resolver na raiz.
Quem poderia faze-lo:  IBGE, Petrobras, OGC ?

[]s
julio menezes

[yjmenezes]

Luiz Paulo / All

Em quarta-feira, 25 de fevereiro de 2015 11:32:04 UTC-3, Luiz Paulo escreveu:

Bom dia. 

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.  

Mai uma informacao que pode interessar:

A cidade de Curitiba, bem como Brasilia, possuem parametros proprios.
O IPPUC de Curitiba usa um SAD69 cujos parametros para levar para SIRGAS2000 sao:
dX= -66.163,  dY=2.028 e dZ=-33.718

Estes parametros diferem dos do IBGE e que eu saiba nao estao cadastrados com um codigo EPSG.

Fica o alerta. Nao eh questao de usar os parametros mais novos e sim os corretos para os dados envolvidos.

[]s
julio menezes


http://cartognu.org/geoshell/2014-12/xdatum.zip

[Jaderson Felipe]

Perdoai meu comentário depois de tanto tempo, mas é que sou novo na area...

Entao deixa eu ver ser entendi, eu crio o SRC dos SAD69, ai para fazer a conversão basta salva como Sirgas 2000 pq o Sirgas esta correto, é isso?

eu uso UTM e notei que usa longlat.

Desculpa as perguntas "bobas" mas é que estou meio perdido pra fazer essa conversão, atualmente jogo tudo no ProGrind e depois faço, imagina o tempo que nao perco nesse processo. 

[Ezequiel Faria]

Olá Luiz e demais colegas, estou com algumas dificuldades segue meu ralato.

Dificuldades nos parâmetros de transformações:

 

Quando transformo de córrego para sad69 utilizando src personalizada (com os parâmetros ibge), observei que o shp cai no mesmo lugar sad 69(96) epsg 5533 caso eu fizesse esta transformação de córrego para sad69(96) epsg 5533 sem parâmetros personalizados ibge.

 

 

Quando transformo de córrego para sad69 epsg 29193 com parâmetros personalizados do ibge no arcgis, observei que o novo shp cai onde estão os arquivos sad69 epsg 29193 retirado do qgis sem src personalizado (apenas salvando com nova epsg um arquivo original em córrego para sad69 epgs 29193).

 

Resultado: quando pego o shp proveniente de uma transformação personalizada feita no qgis (com os parâmetros ibge), cujo o shp personalizado sai com o mesmo posicionamento da epsg 5533 de sad69(96) já existente no qgis. E posteriormente pego um shp proveniente de uma transformação personalizada córrego para sad69 (96) com epsg 5533 (com os parâmetros ibge) feita no arcgis e coloco os dois shp juntos com parâmetros personalizados pelo ibge, ambos não caem no mesmo lugar.

 

No final das contas fazendo uma transformação de shp utilizando parâmetros ibge de córrego para sad69 os shp não estão batendo, quando coloco arquivos no arcgis ou no qgis.

 

Notas:

Valores dos parâmetros de transformações SAD69 (material em anexo) coincide com epsg 5533 (no caso qgis)

 

Fontes:

Parâmetros do qgis:

http://www.processamentodigital.com.br/wp-content/uploads/2014/11/20141105_QGIS24_SRC_Personalizado.pdf

 

Parâmetros do Arcgis:

http://www.processamentodigital.com.br/wp-content/uploads/2015/06/ArcGIS103_Reprojecao_de_SAD1969_para_SIRGAS20001.pdf

 

http://www.ufrgs.br/engcart/Teste/refer_exp.html

att.

Em quarta-feira, 25 de fevereiro de 2015 11:32:04 UTC-3, Luiz Paulo escreveu: