Tag análise-espacial

A Digital Globe, gigante do sensoriamento remoto anda inovando.

Apenas neste ano, vimos surgir sua própia Maps API, que permite ao desenvolvedor a criar aplicativos usando imagens diretamente da Digital Globe.

Logo depois, surgiu o [GBDX] uma plataforma em nuvem para execução de algoritmos a serem aplicados a enorme biblioteca de imagens da empresa.

Agora, mais uma, usando esse conjunto citado acima. O lançamento é do aplicativo Penny.

O Penny é uma IA (inteligência artificial) criada para detectar e prever riqueza. Mas como isto é possível?

Analisando e cruzando dados de satélite com dados do censo americano, é possível treinar uma rede neural ou qualquer algoritmo de machine learning que se queira para estimar a probabilidade de uma área ser rica ou pobre, baseado nos dados do entorno.

Os passos básicos são:

1. Adquirir dados do Censo;
2. Comparação entre os dados vetoriais com os dados de imagens;
3. Treinamento de uma rede neural, cruzando feições com as informações do censo sobre renda;

Exemplo (e um chute):

1. No bairro X existem dois shoppings e a renda é mais alta;
2. No bairro Y existem mais estacionamentos e a renda é média;
3. No bairro Z existem mais parques e a renda é baixa;
4. No bairro X1 existem mais árvores e a renda é mais alta;

A partir de algumas premissas e identificação de feições chave, foi possível cruzar e prever quais tipos de construções/pólos aumentam o valor da renda em determinado lugar.

Isto não quer dizer que as pessoas ficam mais ricas, apenas que pessoas mais ricas frequentam aquele lugar.

Claro que isto é um experimento. A Digital Globe ainda permite que você altere o mapa, colocando partes de outras imagens no local onde você está. Por exemplo, é possível “gentrificar” ou “aumentar o valor da renda” de uma área, colocando mais árvores ou prédios de luxo, como o Empire State Building.

É uma aplicação interessante que mostra para nós como vai ser o futuro do sensoriamento remoto.

Olá pessoal!

Aqui na SIGMA sempre estamos desenvolvendo ferramentas úteis para nós e que talvez também sejam úteis para outras pessoas.

Nossa ideia principal, é contribuir um pouco com esse enorme ecossistema Python/Django existente. Como já disseram, estamos sobre os ombros de gigantes.

Bem, desenvolvemos o Django Topology com o objetivo de simplificar a validação de dados geométricos/geográficos que encontramos em nosso dia a dia.

É muito comum, por exemplo, ter de validar a entrada de um polígono e precisamos garantir que ele esteja dentro de outro polígono. Ou garantir que este polígono específico não esteja sobrepondo outro polígono de uma mesma classe.

Para isso desenvolvemos o Django Topology. Através dele você consegue configurar suas validações dentro do banco de dados e executá-las de forma simples.

O fluxo é simples e o pacote já conta com três validações:

• must be contained – garante que o modelo A deve estar contido no modelo B;
• must not overlap – garante que o modelo A não pode sobrepor nenhum outro registro em A;
• must not overlap with – garante que o modelo A não pode sobrepor o modelo B;

O pacote é facilmente extensível e você desenvolver suas próprias validações topológicas.

Um exemplo simples:

        rule = Rule(
            name='regra de validação 1',
            description='A deve estar contido em B',
            message='deve estar contido',
            method='topology.rules.must_be_contained'
        )
        rule.save()
        topology_rule = TopologyRule(
            content_type_a=ContentType.objects.get(app_label='seuapp', model='item'),
            content_type_b=ContentType.objects.get(app_label='seuapp', model='container'),
            geom_field_b='geom',
            rule=rule
        )
        topology_rule.save()

Até aqui, definimos nossa regra topológica, de que A (qualquer instância do modelo Item) deve estar contida em B (Container).

Veja como realizar a validação:

        item_a = Item(geom=unit_polygon(Point(x=0.0, y=0.0, srid=4326)))
        item_a.save()
        container = Container(geom=unit_polygon(Point(x=0.0, y=0.0, srid=4326), size=3))
        container.save()

        errors = topology_rule.validate(item_a)
        len(errors)
>>> 3

No exemplo acima, calculamos os erros diretamente pela regra topológica (TopologyRule) e não foi encontrado nenhum erro.

Os erros gerados pelo TopologyRule não são persistidos no banco de dados, ficando a cargo do desenvolvedor a determinar o melhor momento para tal. As vezes nem será necessário, como por exemplo, em uma validação de formulário Django.

Também desenvolvemos um análogo ao TopologyChecker do QGIS e ele tem o mesmo nome. Sua função é executar todas as validações associadas a um determinado modelo, de uma vez, e persisti-las (ou não).

Veja como usá-lo:

        # definindo as regras
        rule1 = Rule(
            name='A não deve sobrepor A',
            description='A não deve sobrepor A',
            message='sobrepõe',
            method='topology.rules.must_not_overlap'
        )
        rule1.save()
        rule2 = Rule(
            name='A não deve sobrepor B',
            description='A não deve sobrepor B',
            message='sobrepõe',
            method='topology.rules.must_not_overlap_with'
        )
        rule2.save()
        topology_rule1 = TopologyRule(
            content_type_a=ContentType.objects.get(app_label='seuapp', model='item'),
            rule=rule1
        )
        topology_rule1.save()
        topology_rule2 = TopologyRule(
            content_type_a=ContentType.objects.get(app_label='seuapp', model='item'),
            content_type_b=ContentType.objects.get(app_label='seuapp', model='container'),
            geom_field_b='geom',
            rule=rule2
        )
        topology_rule2.save()

        item1 = Item(geom=unit_polygon(Point(x=0.0, y=0.0, srid=4326)))
        item1.save()
        item2 = Item(geom=unit_polygon(Point(x=0.0, y=0.0, srid=4326)))
        item2.save()
        container = Container(geom=unit_polygon(Point(x=0.0, y=0.0, srid=4326), size=2))
        container.save()

        # até aqui, criamos nossas regras e os registros de item e container

        topo_checker = TopologyChecker()

        errors = topo_checker.validate_all(Item)

O TopologyChecker retorna um dicionário, usando como chave o nome da validação executada e uma lista associada, com N erros detectados. No caso acima, o topologychecker encontrou 4 erros:

• item 1 sobrepõe item 2;
• item 2 sobrepõe item 1;
• item 1 sobrepõe Container 1;
• item 2 sobrepõe COntainer 1;

Estamos usando o Django Topology em produção no Geoadmin um produto que trabalha intensivamente com dados geográficos.

Você pode extender o mesmo com suas próprias validações. Basta criar um método com a seguinte assinatura:

def minha_validacao(rule, feature, **kwargs):
    # sua validacao aqui
    # deve retornar uma lista de TopologyError (sem salvar no banco)
    if feature.geom.intersects(outra_geometria):
        return [TopologyError()]

    return []

Com este método pronto, você só precisa criar uma Rule, apontando o atributo method para o caminmho qualificado da sua função:

rule = Rule(
    name='name'
    method='foo.bar.minha_validacao
)

Quer ajudar? Estamos aí, confere o repositório e bora lá.

A projeção UTM (Universal Transverse Mercator) é muito utilizada para todos os tipos de cartografia.

Ela nem sempre se aplica a todos os casos e deveria ser menos utilizada em algumas aplicações, mas com toda certeza é bastante comum no Brasil e no mundo.

Uma das características marcantes desta projeção, é que ela não é uma projeção única. São 60 zonas com parâmetros diferentes, para cada local do planeta, dividido a cada 6 graus de longitude.

Vou ensinar algumas mágicas utilizando princípios simples para se descobrir maiores informações, necessárias quando estamos trabalhando com essas zonas.

Zona UTM > Meridiano Central

O meridiano central de uma zona UTM é o local que possui a menor distorção da projeção.

Podemos calculá-lo, seguindo a fórmula:

MC = (6 * Z) - 183

Veja o exemplo:

MC = (22 * 6) - 183
MC = 132 - 183
MC = -51

Um outro exemplo, com a zona 30:

MC = (30 * 6) - 183
MC = 180 - 183
MC = -3

Para encontrar os limites de uma zona UTM, adicione 3 graus para o limite oeste e subtraia 3 graus para o limite leste.

MC = -51
Limite Leste = -51 - 3
Limite Leste = -54
Limite Oeste = -51 + 3
Limite Oeste = -48

Longitude > Meridiano Central

Este cálculo é importante: baseado no valor X (ou longitude), você consegue descobrir qual é o meridiano central da zona daquela coordenada.

# nota a divisão de longitude por 6 deve considerar apenas valores inteiros
MC = (6 * int(longitude/6)) + 3
MC = (6 * (-48/6)) + 3
MC = (6 * -8) + 3
MC = -45

Meridiano Central > Zona UTM

Com este cálculo, você informa o meridiano central e descobre qual zona UTM ele está inserido.

UTMZ = 30 - absoluto(int(MC/6))
UTMZ = 30 - absoluto(int(-45/6))
UTMZ = 30 - absoluto(int(-7.5))
UTMZ = 23

São três continhas fáceis de serem realizadas, que ajudam muito na hora de trabalhar com UTM.

O avanço da tecnologia da informação nos últimos 20 anos proporcionou grande impacto na vida dos profissionais na área da cartografia. A cartografia digital, com a evolução dos softwares e equipamentos de coleta de dados transformaram todo processo de produção cartográfica, tornando-o mais rápido e eficiente.
Com tanta facilidade e acesso a estas novas tecnologias, os produtos gerados nas diversas esferas e pelos diversos profissionais constituem uma enorme fonte de informação. Mas, mesmo com tanta informação gerada, não conseguimos encontrar com facilidade aquele base cartográfica específica de hidrografia ou sistema de transportes. E quando encontramos, muitos arquivos estão sem informações essenciais (fonte do levantamento, método utilizado, etc…) e outros apresentam tabela de atributo sem nenhuma informação correta ou estruturada. Para normalizar e organizar esta situação, a implantação da INDE (Infraestrutura Nacional de Dados Espaciais) torna-se essencial para melhor gestão das informações geográficas existentes no Brasil.
######O que é a INDE?
A INDE é o “conjunto integrado de tecnologias; políticas; mecanismos e procedimentos de coordenação e monitoramento; padrões e acordos, necessário para facilitar e ordenar a geração, o armazenamento, o acesso, o compartilhamento, a disseminação e o uso dos dados geoespaciais de origem federal, estadual, distrital e municipal.” Tem como principais objetivos:

1. promover o adequado ordenamento na geração, armazenamento, acesso, compartilhamento, disseminação e uso dos dados geoespaciais;
2. promover a utilização, na produção dos dados geoespaciais pelos órgãos públicos das esferas federal, estadual, distrital e municipal, dos padrões e normas homologados pela Comissão Nacional de Cartografia – CONCAR; e
3. evitar a duplicidade de ações e o desperdício de recursos na obtenção de dados geoespaciais, por meio da divulgação da documentação (metadados) dos dados disponíveis nas entidades e nos órgãos públicos das esferas federal, estadual, distrital e municipal.

Um desafio grande da INDE está na utilização dos padrões e normas homologados pelo CONCAR nos órgãos públicos, principalmente naqueles onde não há setores ou profissionais capacitados para gestão de dados geográficos. Atualmente, o Exército Brasileiro, a partir da DSG (Diretoria de Serviço Geográfico) tem o encargo de elaborar Normas Técnicas para o Sistema Cartográfico Nacional no que concerne às séries de cartas gerais das escalas de 1:250.000 e maiores (Decreto-Lei 243, de 28/02/1967, Art. 15, §1º, item 2.). As normas elaboradas estão disponibilizadas no portal do portal do exército (http://www.geoportal.eb.mil.br/index.php/inde2), caso você ainda não conheça segue descrição:

ET-EDGV – Especificação Técnica para Estruturação de Dados Geoespaciais Vetoriais (define um modelo conceitual);

ET-ADGV – Especificação Técnica para a Aquisição de Dados Geoespaciais Vetoriais (define regras de aquisição da geometria dos dados);

ET-PCDG – Especificação Técnica de Produtos de Conjuntos de Dados Geoespaciais (define os padrões dos produtos vetoriais e matriciais);

ET-RDG – Especificação para a Representação de Dados Geoespaciais (garante a consistência na representação das classes de objetos);

ET-CQDG – Especificação Técnica para o Controle de Qualidade dos Produtos de Conjuntos de Dados Geoespaciais (define os procedimentos para o controle de qualidade dos produtos);`

Caso você utilize QGIS na produção de dados cartográficos, instale o plugin DSG Tools para utilizar funcionalidades de banco de dados (criar base dados no modelo da INDE) e camadas wms, com imagens de satélite rapideye e landsat e camadas de cartas topográficas, tudo disponibilizado pelo exército.

Na próxima postagem iremos demonstrar como produzir dados vetoriais a partir do modelo da EDGV, utilizando um banco de dados spatialite criado pelo DSG Tools.

Maiores informações sobre assunto você econtra aqui:

http://www.inde.gov.br/
http://www.geoportal.eb.mil.br/index.php/inde2

Não é segredo algum, mas todos sabemos que o PostGIS é a extensão espacial mais produtiva do mundo. Ela não só possui mais funcionalidades do que as outras disponíveis no mercado, mas como é open-source, com uma comunidade incrível por trás.

Hoje vou revelar alguns pequenos segredos escondidos nas funcionalidades do PostGIS para vocês. Estas funções, com toda certeza, irão te tornar mais produtivo e efetivo no uso desta ferramenta tão legal.

1. Escrita de Geometrias

Ler e escrever faz parte do básico do PostGIS. Existem várias funções que permitem a leitura e a escrita de geometrias no formato que o PostGIS espera.

Existem funções para conversão de texto para geometria, bytes para geometria e outros formatos. Mas a campeã de flexibilidade para testes rápidos e verificações é a ST_GeomFromText.

Veja abaixo um exemplo de como usá-la:

SELECT * FROM ST_GeomFromText('POINT(0 0)', 4326);

Veja a saída do PostGIS, no formato interno.

0101000020E610000000000000000000000000000000000000

Lembro, que esta funcionalidade não é somente útil para a conversão para o formato esperado, mas também para usar seu resultado como entrada para outras funções, como no exemplo:

-- o polígono interseciona o ponto?
SELECT * FROM ST_Intersects(
    ST_GeomFromText('POLYGON((0 0, 0 1, 1 1, 1 0, 0 0))', 4326),
    ST_GeomFromText('POINT(0 0)', 4326)
);

Retornando um resultado positivo:

t

A assinatura desta função é bem simples. Ela espera como primeiro parâmetro uma string e opcionalmente um inteiro, representando o SRID (Spatial Reference ID). Nos exemplos foi usado WGS-84 como SRID.

Referência: ST_GeomFromText

2. Validade de Geometrias

A validade das geometrias é uma questão importantíssima para qualquer tipo de uso em pacotes de geoprocessamento.

É bom lembrar que o único tipo de geometria (definido na [SFS] (Simple Feature Specification) que possui validade são os tipos poligonais (Polygon e MultiPolygon). Os outros tipos podem ser testados para sua validade, mas ela é sempre verdadeira.

Geometrias inválidas não podem ser corretamente renderizadas e irão “mentir” quando investigadas sob diversos aspectos – notavelmente, cálculos de área e testes de interseção podem falhar com geometrias inválidas.

No PostGIS, existem algumas formas de se verificar a validade de geometrias. São três funções simples que podem te ajudar a identificar culpados. As funções são:

• ST_IsValid – Verifica a validade de uma geometria e retorna verdadeiro ou falso.
• ST_IsValidReason – Verifica a validade de uma geometria e retorna a razão pela qual a mesma é inválida, exemplo: auto intersecção.
• ST_IsValidDetail – Verifica a validade de uma geometria e retorna o motivo e a localização do problema, exemplo:

SELECT * FROM
    ST_IsValidDetail(
        ST_GeomFromText('POLYGON((0 0, 0 -1, 0 1, 1 1, 1 0, 0 0))', 4326)
    );

O resultado, neste caso, é uma tupla com três elementos: valid, reason e location:

f;"Self-intersection";"01010000000000000000000000000000000000F0BF"

3. Transformação de Referência Espacial

O PostGIS suporta mútliplas referências espaciais. Tradicionalmente, isto é conhecido por um código EPSG , o SRID.

SRID é a abreviação para Spatial Reference System Identifier, definido originalmente pelo EPSG. É um código único que identifica um sistema de referência espacial, com todos as suas variações de datum, projeção e sistema de coordenadas.

EPSG é a abreviação para Euroupean Petroleum Survey Group – que não existe mais, foi absorvido pelo IOGP (International Association of Oil and Gas Producers).

Geralmente, cada tabela no PostGIS, possui apenas uma coluna geométrica, com um SRIDdefinido. Apesar disso, o PostGIS suporta múltiplas colunas geométricas em uma mesma tabela e até mesmo colunas geométricas com referências espaciais nulas.

A multiplicidade de dados geográficos faz necessária a conversão entre diferentes SRIDs. Lembramos também que comparações e testes de relacionamento entre geometrias (como se uma geometria interseciona outra) devem ser feitos apenas se ambas geometrias possuem o mesmo sistema de referência espacial.

Um exemplo simples, é a conversão de uma coordenada UTM, na zona 22 Sul em SIRGAS 2000 para SIRGAS 2000 geográfico:

SELECT * FROM 
    ST_AsText(
        ST_Transform(
            ST_GeomFromText(
                'POINT(789071 7905599)', 31982),
                4674
            )
        )

Note que na chamada acima, usamos ST_GeomFromText para “instanciar” as geometrias em memória, de coordenadas geográficas, transformamos as mesmas com ST_Transform e pedimos sua representação textual com ST_AsText.

Para referências de códigos EPSG e SRIDs, use o site epsg.io. Abaixo estão as duas URLs as referências espaciais usadas no comando acima:

• 31982 – SIRGAS 2000 UTM 22S;
• 4674 – SIRGAS 2000 – Geográfico;

Conclusão

Apesar de discutirmos neste artigo, funções básicas do PostGIS, elas são muito úteis em todos os cenários, seja no desenvolvimento de sistemas com o PostGIS ou utilizando o PostGIS como motor de análise espacial.

Este é um dos primeiros artigos sobre PostGIS. Fique ligado aqui no blog que logo logo teremos mais.

Abraços