[Portugal] Re: Disponível o manual de QGI S 1.6

[Joaquim Luis]

On 15-12-2010 09:25, Jose Gonçalves wrote:
> Olá
>
>     Imodéstia à parte, eu conheço bem esta questão dos formatos e
>     tipos de dados em que eles são difundidos.
>
>
> Não tenho a mínima dúvida, nem eu escrevi o e-mail anterior com 
> qualquer fim "didático". Foi só porque me pareceu ficar essa ideia de 
> separação de conceito pelo tipo de dados.

Desculpa, acabou por ser pedande mas já era muito tarde e não apeteceu 
estar a elaborar mais sobre 1, 2, 4 ou 8 bytes.
Mas eu não tenho nada contra mails didáticos, bem pelo contrário e este 
puxa um tema que é importante e tem sido fonte de muitos erros.
Curiosamente, já antes do geotiff, o GMT tinha introduzido estes 
conceitos cahamando-lhe "grid registration" e "pixel registration"

http://gmt.soest.hawaii.edu/gmt/doc/gmt/html/GMT_Docs/node185.html

Sendo eu também da "escola Surfer" durante muitos anos nem sequer me 
passava pela cabeça usar outra coisa que não "grid registration" para 
grelhas. Contudo, quando olhamos ao que se passa no GDAL vemos que há 
pessoas para quém tudo é "pixel registration". À conta disto houve 
vários bugs no GDAL na conversão de formatos que durarm anos.
Um exemplo de como a mistura destes dois modelos podem confundir as 
pessoas é este. Imaginemos que no Surfer calculamos uma grelha global 
([0 360] x [-90 90]) com um passo de malha de 2 gráus. Se perguntarmos 
os seu limites ao Surfer ele afixará

[0 360] x [-90 90]

se fizermos os mesmo com o GADL (com a mesma grelha claro), ele dirá

[-1 361] x [-91 91]

O argumento do GDAL é o de que o seu modelo é "pixel" portanto todos os 
utilizadores devem estar cientes disso. Certo, é um argumento válido. 
Uma outra perspectiva, igualmente defensável, é que o resultado está 
pura e simplesmente errado.
Aqui volto a fazer propaganda ao "meu" GMT onde ambos os modelos são 
respeitados e tem ferramentas para passar de um a outro. Aliás, as 
grelha netCDF produzidas por ele têm internamente uma codificação para 
distinguir/permitir entre os dois modelos. Claro que no meu exemplo 
anterior o GMT dará a resposta que se espera, ou seja que a Terra não 
inchou.

Os SRTM passaram de facto de grid para pixel, o que por um lado implica 
que as grelhas foram reinterpoladas e por outro a minha má língua me 
leva a pensar que isso foi feito porque muitos softs não sabiam 
distinguir entre um e outro e quando colavam os azuleijos (tiles) lado a 
lado faziam o error de não remover a linha em comum (que aliàs nem 
sempre era exactamente igual entre os dois).

Joaquim

>
> Uma questão de conceito que vejo com os rasters e grelhas é a de saber 
> se num conjunto de dados matricial um valor corresponde a todo o 
> quadrado (ou rectângulo) de um pixel ou se corresponde a um ponto (no 
> formato geotiff há um "flag" que indica "pixel is an area" ou "pixel 
> is a point"). A diferença entre eles é que o tamanho do pixel e a 
> cobertura se relacionam, respectivamente, como:
>
> pixel_x = (xmax-xmin) / numero_colunas
> pixel_y = (ymax-ymin) / numero_linhas
>
> pixel_x = (xmax-xmin) / (numero_colunas-1)
> pixel_y = (ymax-ymin) / (numero_linhas-1)
>
> Uso o termo "grelha", talvez por influência do programa Surfer, para o 
> segundo caso. O conceito é o mais adequado para um MDT, já que permite 
> a interpolação bilinear para qualquer local da cobertura do ficheiro. 
> No Arcinfo era usada a palavra "lattice", mas deixei de a ver usada, 
> quer no Arcgis, quer noutros programas.
>
> Para as "imagens" aplica-se o primeiro conceito. Por exemplo um 
> ortofoto que cubra a área de uma folha da carta militar 1:25,000 terá 
> 16000 por 10000 pixeis e duas folhas vizinhas não terão sobreposição.
>
> Claro que os dois conceitos se podem usar com os mesmos dados. Veja-se 
> por exemplo os MDTs do SRTM, que na distribuição no formato HGT, são 
> "grelhas" (1201 por 1201) e na distribuição "seamless" do USGS uma 
> quadrícula de 1 grau tem 1200 por 1200 pixeis.
> Para mim uso o termo "grelha" como referi atrás.
>
> Cumprimentos
>
> José A. Gonçalves

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/portugal/attachments/20101215/aed6f2a4/attachment.html