Problema com o Sistema de Referência de Coordenadas (SRC)

[Guilherme Almeida]

Prezados colegas de comunidade,

Estou trabalhando na elaboração da escolha de áreas susceptíveis a implantação de aterro sanitário e estou com dificuldade para escolher o SRC adequado. Eu estou trabalhando com diversas fontes de dados (IBGE, DNIT, MMA, etc.). Eu já projetei todas as camadas para o EPSG:XXXX e esse SRC as aglutinou, até aí tudo bem. O problema, no entanto, é que sempre há um erro significativo ao gerar o buffer (50 m a mais para um buffer de 500 m, por exemplo). Além disso, teria que rasterizar os buffers com um certo peso e, posteriormente, somar todas as camadas raster, gerando as áreas almejadas. (1) TODOS os vetores precisam estar no mesmo SRC para que não haja nenhum erro nas etapas seguintes? (2) Por que há esse acréscimo na geração do buffer? Outro fato bem estranho é que, no momento da geração do buffer, eu tenho que trabalhar com números decimais. Exemplo: eu tenho que preencher o campo do tamanho do buffer com 0,005 para gerar um buffer de 500 m. (3) Isso está correto?

Agradeço desde já pelo retorno.

Abs.

[Leônidas Descovi Filho]

Olá Guilherme 

Teu problema parece ser o SRC. Trabalhe com o mesmo sistema UTM para todas camadas e projeto.

Poste aqui o resultado.

Abs e Boa sorte 

--
Comunidade QGIS Brasil: http://qgisbrasil.org/
---
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 https://groups.google.com/group/qgisbrasil.
Para mais opções, acesse https://groups.google.com/d/optout.

[yjmenezes]

@Guilherme

Muito provavelmente seus dados estao em WGS84 EPSG4326 Lat/Lon ou em SIRGAS2000. EPSG:4674.
Por esta razao esta usando 0.005 graus para fazer o buffer de 500 metros.
Nao sei sua latitude mas segue um codigo Python, que portei de um antigo codigo AWK para UNIX.
https://github.com/kylefelipe/qgis-tips-tricks/blob/master/shell/raio_curv.awk

Com isso voce pode ajudar a calcular com mais precisao e continuar usando Lat/Lon para gerar os buffers.

A saida do Python sera algo tipo:

jmenezes@gnu000:/tmp$ ./raio_local.py
lat= -31.767 raio= 6375818.192484699
100m=  0.0008986419904604239 deg
500m=  0.00449320995230212 deg
1km=  0.00898641990460424 deg
111km=  0.9974926094110704 deg
1 deg= 111279.01996741159 m

bom trabalho.

Em domingo, 8 de julho de 2018 00:23:33 UTC-3, Leônidas Descovi Filho escreveu:

Olá Guilherme 

Teu problema parece ser o SRC. Trabalhe com o mesmo sistema UTM para todas camadas e projeto.

Poste aqui o resultado.

Abs e Boa sorte 

Em Sáb, 7 de jul de 2018 22:57, Guilherme Almeida <guilherm...@gmail.com> escreveu:

Prezados colegas de comunidade,

Estou trabalhando na elaboração da escolha de áreas susceptíveis a implantação de aterro sanitário e estou com dificuldade para escolher o SRC adequado. Eu estou trabalhando com diversas fontes de dados (IBGE, DNIT, MMA, etc.). Eu já projetei todas as camadas para o EPSG:XXXX e esse SRC as aglutinou, até aí tudo bem. O problema, no entanto, é que sempre há um erro significativo ao gerar o buffer (50 m a mais para um buffer de 500 m, por exemplo). Além disso, teria que rasterizar os buffers com um certo peso e, posteriormente, somar todas as camadas raster, gerando as áreas almejadas. (1) TODOS os vetores precisam estar no mesmo SRC para que não haja nenhum erro nas etapas seguintes? (2) Por que há esse acréscimo na geração do buffer? Outro fato bem estranho é que, no momento da geração do buffer, eu tenho que trabalhar com números decimais. Exemplo: eu tenho que preencher o campo do tamanho do buffer com 0,005 para gerar um buffer de 500 m. (3) Isso está correto?

Agradeço desde já pelo retorno.

Abs.

--
Comunidade QGIS Brasil: http://qgisbrasil.org/
---
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+unsubscribe@googlegroups.com.

[Guilherme Almeida]

Olá pessoal,

Vou testar as dicas e volto com o resultados.

Abs.

[Instrutor GIS]

Talvez seja melhor trabalhar no Sistema de Coordenadas Planas. Como você possui dados diversos e provavelmente em grandes extensões de área, seria melhor utilizar a Projeção Cônica Equivalente de Albers para Áreas Iguais.

Não vale a pena trabalhar no Sistema Geográfico. Neste caso, você vai trocar a Projeção UTM (que é uma particularidade da Mercator) pela Projeção Cônica.

Faça a reprojeção de todos os seus dados do Sistema Geográfico para o Sistema Projetado utilizando o código EPSG:102033.

​

Jorge Santos
Instrutor de Geotecnologias
http://www.instrutorgis.com.br
jorgep...@outlook.com
WhatsApp: (61) 99616-5665
Skype: jorgepsantos2002
https://www.linkedin.com/in/jorgepsantos
Twitter: http://twitter.com/jpsantos2002

--

Comunidade QGIS Brasil: http://qgisbrasil.org/
---
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.

[Guilherme Almeida]

Olá pessoal,

Eu mudei todos os SRC para o EPSG:31984. Tive problemas para fazer isso porque, utilizando o algoritmo "Reproject layer" rodando como lote para reprojetar tudo de uma única vez, apenas alguns shapes foram reprojetados corretamente. Para outros, tive que mudar a projeção para EPSG:4326 (pelas Propriedades do arquivo, sem utilizar o vetor de reprojeção) e, por fim, fui em "Salvar como" e em projeção escolhi a EPSG:31984.

Vocês sabem por quê isso ocorreu? É o arquivo? Algum bug no algoritmo? É estranho que o algoritmo não consiga reprojetar o shape da forma correta.

Quanto a sua dica, Jorge, é melhor segui-la ou continuar com o que eu já fiz?

Abs.

Em sábado, 7 de julho de 2018 22:57:29 UTC-3, Guilherme Almeida escreveu:

[yjmenezes]

@Guilherme:

Veja seus EPSG:
Se 4326 ou 4647, os dados estao em Lat/Lon e voce deve definir o buffer em GrausDecimais. 1 segundo de arco corresponde a 1/3600 graus ( aproximadamente 30 metros,  depende de sua latitude ).
Se seus dados estiverem em UTM SIRGAS 2000/24S, EPSG:31984, voce define o buffer em metros.

[]s
julio
cartognu.org
PS: bugfix python

[Kyle Felipe]

Muitas coisas podem ter acontecido, nome de pastas com caracteres especiais e espaço, nomes dos arquivos...

Em terça-feira, 10 de julho de 2018 17:00:12 UTC-3, Guilherme Almeida escreveu:

[Instrutor GIS]

Você pode realizar a reprojeção em lote, não há problema. Acontece que, primeiro, antes de realizar a reprojeção, você precisa conhecer o sistema de origem das camadas.

Se todos os dados geográficos estão enquadrados nos limites do Fuso 24, não precisa mudar o sistema para Albers. Você fez certo em manter o sistema SIRGAS 2000 UTM 24 S. Agora, se há camadas posicionadas entre dois ou mais fusos, você terá problemas com a projeção UTM. 

A reprojeção em lote só faz sentido se os dados originais estiverem referenciados no mesmo sistema. Eu costumo verificar, um a um, o sistema das camadas de entrada.

Jorge Santos
Instrutor de Geotecnologias
http://www.instrutorgis.com.br
jorgep...@outlook.com
WhatsApp: (61) 99616-5665
Skype: jorgepsantos2002
https://www.linkedin.com/in/jorgepsantos
Twitter: http://twitter.com/jpsantos2002

--

[yjmenezes]

@Guilherme,

Meus 20 cents:

Antes de mais nada,
1: verifique os dados que tem disponiveis e os respectivos EPSG, precisoes, resolucao geometrica...
2- veja os algoritmos e processos que vai precisar e o que deseja como produto final.
3- prepare os dados para processamento efetuando reprojecoes, se isso for realmente necessario.

good luck !

[]s
julio
cartognu.org
PS: use 6 ou 7 decimais para os  graus decimais.

Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para qgisbrasil+unsubscribe@googlegroups.com.

[Guilherme Almeida]

Já consegui agrupar todas as camadas no mesmo SRC.

Obrigado pela disposição de todos. @yjmenezes, não sei se seria viável utilizar a sua dica porque eu tenho que criar buffers com vários tamanhos diferentes (100 m, 200, 250 m e por aí vai). Agora vou criar os buffers e volto em caso de algum outro problema.

Abs.

Em sábado, 7 de julho de 2018 22:57:29 UTC-3, Guilherme Almeida escreveu:

[Guilherme Almeida]

Prezados,

Dando seguimento ao trabalho eu notei que há uma grande diferença entre os algoritmos nativos do QGIS e aqueles do GRASS. Ao rasterizar um vetor, por exemplo, a saída dos algoritmos nativo e do GRASS são, respectivamente, ~44 MB e ~1,6 MB. É uma diferença gigantesca. Eu notei que o algoritmo do QGIS produz um raster que inclui os pontos sem valor; já o algoritmo do GRASS não faz isso, ele isola o buffer e deixa os pontos sem valor fora do raster. Esse é o principal motivo pela qual o arquivo de saída do QGIS é muito maior que o do GRASS? Acredito que o GRASS seja mais otimizado, mas gostaria da opinião de quem tem mais experiência.

Em sábado, 7 de julho de 2018 22:57:29 UTC-3, Guilherme Almeida escreveu:

[Instrutor GIS]

Quais algoritmos produzem esses resultados, Guilherme? Não notei essa diferença aqui.

Jorge Santos
Instrutor de Geotecnologias
http://www.instrutorgis.com.br
jorgep...@outlook.com
WhatsApp: (61) 99616-5665
Skype: jorgepsantos2002
https://www.linkedin.com/in/jorgepsantos
Twitter: http://twitter.com/jpsantos2002

--

Comunidade QGIS Brasil: http://qgisbrasil.org/
---
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.

[Guilherme Almeida]

Jorge, são os algortimos Buffer de distância fixa e o v.buffer.distance.

Em sábado, 7 de julho de 2018 22:57:29 UTC-3, Guilherme Almeida escreveu: