PostGIS atualizou e a base de dados quebrou?

A mensagem de erro é a seguinte:
An error has occured: ERROR. could not access file “$libdir/postgis-2.1”: No such file or directolry.

A solução é fácil. A nova versão de PostGIS está numa nova pasta e temos de indicar isso a PostgreSQL. Depois, fazer o ALTER EXTENSION em cada uma das base de dados, para que atualize PostGIS.

No Ubuntu e para a versão de PostgreSQL 9.3, fica assim:

SELECT de um determinado ano e dia da semana

Por exemplo, todas as terças-feiras de 2016:

Notas:
generate_Series() – é uma função para gerar uma lista de valores, neste caso de 0 a 365, usados para somar com a data do inicio do ano (2016-01-01).

extract() – tal como o nome indica extrai sub valores de um timestamp ou data. Foi aqui usado para extrair o dia da semana (dow).

dowday of the week. Os valores de dow vão de 0 a 6. Sendo 0 domingo e 6 sábado. Portanto 2 corresponde a terça-feira.

Como alterar a senha desconhecida de administrador de PostgreSQL

Este é apenas mais um exemplo de que uma password não é suficiente para proteger o conteúdo de um computador. O acesso físico ao computador é essencial.

Então suponhamos que se perdeu a senha de administrador de PostgreSQL, ou seja, do utilizador postgres. Primeiro há que ter em consideração que o utilizador postgres existe tanto na base de dados como no sistema operativo. Então vai ser necessário alterar a senha nos dois sítios.

Para alterar a senha no sistema operativo é necessário acesso root ao sistema. Se também perdeu a senha de root, ver aqui primeiro. Se não prosseguir:

Neste ponto a senha de postgres no sistema operativo está atualizada. Resta alterar a senha na base de dados.

Feito!

Função para intersectar geometrias em PostgreSQL + PostGIS

Escrevi esta função para dar resposta a uma operação muito comum em SIG. Intersecção entre geometrias. No entanto, por vezes, as geometrias não se intersectam e nesses casos o que nos gostaria de saber é a que distancia está a geometria mais próxima. Ou mesmo, todas as geometrias que estão dentro uma determinada distancia. Outro fator a ter em conta é a velocidade da consulta. Para acelerar o calculo usa-se o típico a.geom && b.geom e assim a consulta faz uso do bounding box da geometria subjacente. Mas no caso de uma geometria estar fora de todos os bounding box vamos ter como resposta um valor NULL, e isso não é muito informativo. Esta função tentar dar resposta a todas estas questões.

Aspetos a ter em conta.
– Ambas tabelas tem de ter uma PRIMARY KEY.
– Não importa o tipo de geometria (POINT, LINE, POLYGON, …).
– Não importa se as geometrias tem diferentes Sistemas de Coordenadas, a função converte tudo a EPSG:4326 (WGS84) para realizar o calculo.
– Vão ser criados duas colunas, uma para os id‘s da(s) geometria(s) mais próxima(s) e outra para a(s) distancia(s) em metros.
– Se a função se executa mais de uma vez, elimina as colunas anteriores antes de as criar novamente.
– O resultado da distancia é dado em metros.
– O valor de tolerance deve ser dado em metros.
– Se o valor de tolerance é igual a 0, apenas devolve o id de uma geometria, a mais próxima e a sua distancia (0 ou mais).
– Se o valor de tolerance é maior do que 0, devolve uma array com todos os id das geometrias a menor ou igual distancia do valor de tolerance e uma array com as correspondentes distancias. Pela mesma ordem.

Como usar esta função.

SELECT fun_closest_geom(sch_from, table_from, sch_to, table_to, tolerance);

– Caso 1. Queremos saber que geometria da tabela public.tabela2 esta mais próxima das geometrias da tabela public.tabela1. Os resultados escritos na public.tabela1.
SELECT fun_closest_geom(‘public’, ‘tabela1’, ‘public’, ‘tabela2’, 0);

– Caso 2. Queremos saber que geometrias da tabela public.tabela2 estão a <= 1 Km das geometrias da tabela public.tabela1. Os resultados escritos na public.tabela1.
SELECT fun_closest_geom(‘public’, ‘tabela1’, ‘public’, ‘tabela2’, 1000);

Mas antes temos de criar a função, para isso basta executar o seguinte código.

Continidade do legado de 40 anos de Landsat

Outro vídeo falando do que podemos esperar do Landsat 8 e alguns dos seus aspetos técnicos: usos, orbita, instrumentos, resolução espectral, resolução temporal, nova técnica de varrido, centros de receção de dados. E sobretudo, confirmam que continuará a ser de livre acesso. Muito interessante, e apenas 5 minutos e meio.

TIRS – Sensor Infravermelho térmico a bordo do Landsat 8

O Thermal InfraRed Sensor (TIRS) é um dos instrumentos da missão Landsat Data Continuity Mission (LDCM). Continuará o arquivo de imagens térmicas e suportará aplicações emergentes, tal como a medição da evapotranspiração. TIRS está a ser construído pela NASA GSFC e tem uma vida útil de três anos.

Este instrumento irá a bordo do Landsat Data Continuity Mission (LDCM), que tem o lançamento programado para junho de 2013 e será o oitavo da série de satélites Landsat. Desde 1972, os satélites Landsat observaram a Terra a uma escala onde os impactos humanos e mudanças naturais podem ser monitorizadas, diferenciados, e caracterizados ao longo do tempo.

Expansão da cidade de Las Vegas

Com o motivo do 28º aniversário do satélite Landsat 5 no dia 1 de Março a NASA realizou este podcast (mais) onde se mostra um time-lapse da expansão da cidade de Las Vegas de 1972 a 2010.

As grandes áreas vermelhas são em realidade espaços verdes, principalmente campos de golfe e jardins. As imagens tornam-se mais nítidas por volta de 1984, quando um novo desenho dos instrumentos aumentou a sensibilidade.

Estas imagens de Las Vegas foram criados usando a luz refletida a partir das porções do infravermelho próximo, vermelho e verde do espectro eletromagnético (Landsat 5 TM bandas 4,3,2 e Landsat MSS 1-3 bandas 4,2,1).

O próximo satélite Landsat, Landsat 8, está programado para lançamento em janeiro de 2013.

Fonte: http://www.youtube.com/user/NASAexplorer#p/u/1/xFzdyxwx50M

Disparador (trigger) para actualizar automaticamente a área e o perímetro de geometrias em PostgreSQL

Nesta entrada vou explicar como criar um disparador para actualizar automaticamente a área e perímetro das geometrias de uma tabela em PostgreSQL. Para tal, vão-se utilizar as funções ST_Area() e ST_Perimeter() de PostGIS.

Nota: Onde está esquema deve ir o nome do esquema, onde está tabela o nome da tabela e onde está geom o nome do campo com a geometria.

As seguintes linhas são para criar os campos area e perimetro e preencher os campos. Utilizar uma das opções: UTM ou Geográficas, dependendo do sistema de coordenadas do tema.

Decidi utilizar o tipo bigint porque considero que os valores decimais não aportam informação útil para pequenas escalas e iriam ocupar mais espaço na tabela. No entanto, para escalas maiores e se interessa a exactidão, basta com mudar bigint por float.

Agora criamos a função que preenche automáticamente os campos area e perimetro cada vez que uma geometria é inserida ou modificada. Se anteriormente alteraste bigint por float, elimina ‘::bigint’ nas linhas 5 e 6. O resultado por defeito é do tipo float e já não é necessário fazer um cast.

O exemplo dado é para temas com sistemas de coordenadas em metros, como UTM. Se o tema está em geográficas e também se pretende o resultado em metros, deve ir assim:

Eliminamos o disparador no caso de que já exista um com o mesmo nome. Para passar a criar o disparador e indicar quando se deve executar e sobre que tabela.

Agora os valores de área e perímetro da tabela estarão sempre de acordo com a geometria.

Conversão de graus a metros

Um método simples e bastante preciso para converter graus a metros é conseguido utilizando uma consulta SQL em PostgreSQL + PostGIS. Como podemos ver nas seguintes consultas para distintas latitudes: