Todos os posts de George Silva

Boa noite pessoal!

Hoje vamos falar um pouco sobre a metodologia da SIGMA referente a cartografia de larga escala.

Bem, a definição de larga escala pode variar de projeto para projeto, mas geralmente estamos falando de áreas com milhares de objetos geográficos (ou feições) em uma escala de até 1:10.000.

Vou comentar primeiramente da nossa experiência e logo depois irei comentar das ferramentas que desenvolvemos para auxiliar os analistas de geoprocessamento e a gerência a ter uma visão completa do projeto.

Nossa experiência

A SIGMA Geosistemas já executou diversos projetos que podem ser considerados como cartografia de larga escala. Em uma conta rápida, estimo aproximadamente entre 60 e 70 mil km2 mapeados, utilizando apenas tecnologias livres, distribuídos entre os diversos projetos executados.

Uma breve descrição sobre nosso stack tecnológico:

• PostgreSQL + PostGIS;
• pgpool;
• QGIS (diversas versões);
• cartobash;
• X9 (monitor de progresso);

O PostgreSQL com o PostGIS, é sem dúvida, o banco de dados geoespacial mais capaz do mercado. Ele é nossa principal arma para este tipo de projeto, pois é um banco de dados:

1. Robusto;
2. Cheio de funcionalidades importantes para análise espacial;
3. Permite centenas de conexões simultâneas, sem problemas;
4. Fácil de configurar e manter;

Junto ao PostgreSQL, para ajudar a manter estas centenas de conexões simultâneas (cada usuário pode abrir mais de uma conexão ao banco), usamos o pgpool. Ele é responsável por criar um pool de conexões, sem termos a necessidade de recriamos cada conexão a todo momento. Isto nos traz robustez e aumenta o desempenho.

Em cima disto tudo, a estrela: QGIS, de preferência uma versão recente.

O cartobash e o X9 são ferramentas abertas que a SIGMA desenvolveu para auxiliar nesta tarefa.

O cartobash é uma ferramenta escrita basicamente em shell script, que automatiza diversas partes da construção de novos bancos de dados, configuração de logging, backups e issues.

Além disso, o cartobash gerencia versões padrões de projetos QGIS, permitindo que cada analista gere seu arquivo de projeto, insira rapidamente sua senha e configure as diversas camadas daquele projeto.

O X9 é um experimento escrito em Python e Django para ajudar a monitorar o que está sendo feito pelos analistas, em tempo real.

Ele consulta a base de dados e a base de logs, para determinar qual é o total de edições realizadas naquele dia, qual é a porcentagem de progresso do projeto, entre outras métricas interessantes.

Descrita as ferramentas, passamos para a metodologia!

Metodologia

Em temos gerais, passamos pelas seguintes etapas:

1. Definição da abrangência geográfica do projeto;
2. Definição do modelo de dados;
3. Construção do banco de dados com o cartobash;
4. Setup de logging, issues, áreas de trabalho e funcionalidades de validação automatizadas;
5. Construção do projeto padrão QGIS;
6. Delegação de permissão para os analistas;
7. Mãos a obra!isto

Para o início de todos os projetos, o primeiro passo é determinar seu modelo de dados e sua abrangência geográfica.

De posse dessas informações, já saberemos o quão complexo será a construção e digitalização dessa base de dados.

Neste ponto, com o modelo de dados principal, tabelas relacionados (ou auxiliares) prontas, configuramos o logging, issues e áreas de trabalho.
isto
Esta etapa é (e deve ser) automatizada. Tudo isto é feito pelo cartobash. Dividimos o projeto em sub-áreas, utilizando algumas funcionalidades do PostGIS e delegamos as mesmas para os analistas.

As issues também são configuradas nesta etapa. As issues ou não-conformidades são dados geográficos que podem ser utilizados pelos analistas e revisores, para marcar áreas que não estejam de acordo com o padrão de qualidade esperado.

Dependendo do tipo de projeto, configuramos as isto validações automatizadas, como regras topológicas, executadas a cada minuto, podendo ser visualizadas pelos analistas em tempo real.

UFA! O cartobash nos ajuda até aí, então é bem fácil de realizar isso tudo. Basta rodar um comando bash e correr para o abraço.

A parte complicada, é construção do projeto do QGIS. O QGIS permite a construção de formulários customizados, com regras avançadas de relacionamento entre tabelas.

Por exemplo, um tipo de feição possui um campo chamado CLASSE, que só pode ter um dos valores: A, B ou C. Usando as ferramentas do QGIS permitem que você configure e limite as opções do analista, apenas a estas três.

Este é um exemplo simples, mas a partir desta configuração, o projeto padrão é disseminado entre os analistas, que inserem seu próprio usuário e senha do banco de dados.

A partir deste momento, devemos por a mão na massa.

Divisão em sub-áreas

Existe um desafio complexo ao trabalhar com projetos massivos como os que trabalhamos. A sensação de progresso experimentada pelos analistas é bastante pequena, quando não delegamos áreas menores para seus trabalhos.

Caso eles tenham liberdade para escolher as áreas de trabalho, sem uma limitação menor, a sensação de avanço do trabalho é pequena e acabam se desmotivando.

O segredo que permitiu aumentar a produtividade e aumentar a sensação de progresso entre os colaboradores foi a divisão do projeto em áreas menores, assinalando as mesmas a cada analista.

Apesar de funcionar, pode trazer alguns problemas, como a eventual correção de divergências entre as grades, mas em nossa experiência, essas correções são pequenas – fazendo esta estratégia valer a pena.

Conclusão

Neste post tentamos trazer para vocês um pouco nossa experiência com projetos de cartografia de larga escala.

Qual é a sua experiência? Comente conosco!

E você? tem algum projeto de cartografia de larga escala e precisa de ajuda? Conte conosco.

Um abraço!

Nesta postagem iremos falar sobre mais um trabalho da SIGMA que disponibilizamos de maneira open-source. Desta vez iremos falar sobre o Django TileStache.

O TileStache é um servidor de tiles, escrito em Python. É um servidor bastante flexível, bastando uma configuração em JSON para que o mesmo funcione.

Ele é perfomático, mas a limitação dele de funcionar apenas com um arquivo de configuração estava nos incomodando.

O problema

Em algumas de nossas soluções, nossas camadas a serem servidas pelo TileStache são dinâmicas. Isto significa, que depois de determinado evento, precisarei servir novos dados através do TileStache.

Um exemplo claro: dentro do Geoadmin, quando um cliente novo se registra, precisamos servir as camadas que são dele. E isto necessita de uma nova configuração.

A solução

A solução para este problema tem duas partes. A primeira delas foi desenvolver um cadastro de camadas. Este cadastro de camadas já é preparado para funcionar com o Django REST Framework e nos permite cadastrar layers de forma arbitrária. Todos os tipos de providers suportados pelo TileStache são suportados, mas via REST, apenas quatro tipos, por agora:

• External (classes externas);
• Vector (qualquer fonte, PostGIS, Shapefile, Spatialite e JSON);
• Mapnik;
• Proxy;

Usar o cadastro de layers é bastante simples, veja só:

from django_tilestache.models import Layer

layer = Layer.objects.create(
    **{
        'name': 'foolayer'  # this is the tilestache layer name
        'provider': {

        },  # tilestache provider options
        '...' : 'foo' # all other options
    }
)

No exemplo acima, criamos uma layer com o nome de foolayer, mas não demonstramos as opções de provedor. Se você seguir o TileStache, qualquer layer será válida.

A outra parte da solução, consiste num servidor customizado do TileStache. Pegamos o servidor WSGI original e extendemos o mesmo para que de, tempos em tempos, ele faça um request para o servidor de comando e controle (neste caso, a aplicação Django que contém o django-tilestache instalado), que retorna a nova configuração.

Você pode, e deve, inclusive, estabelecer credenciais para isto. A configuração do TileStache contém informações sigilosas e não deve ser exposta diretamente para internet.

Views

Duas views iniciais foram desenvolvidas para suportar algumas questões de desenvolvimento aqui na SIGMA, são elas:

1. TileStacheConfiguration – esta view específica retorna a configuração registrada do TileStache, em formato JSON. Este é o endpoint utilizado para que o TileStache remoto, consiga se atualizar.
2. TileStacheTile – esta view renderiza tiles das camadas registradas, ou seja, caso você não queira, você pode usar esta view para servir seus tiles em seus projetos Django.

Instalação

pip install django-tilestache

Configuração

1. Vá em seu settings.py do Django. Adicione django_tilestache nas INSTALLED_APPS.
2. Rode o comando migrate para criar os modelos no seu banco de dados;
3. Adicione as urls do django-tilestache dentro do das suas URLS. Este passo é opcional. Se você fizer isto, terá de usar a estrutura de URLS definida pelo app. Caso queira alterar esta estrutura, registre suas views manualmente;

Gostou?

O repositório está disponível em: https://gitlab.sigmageosistemas.com.br/dev/django-tilestache. Seja bem vindo e nos ajude na construção deste pacote.

Abraços

No Geoadmin uma das principais questões fundiárias é a gestão da reserva legal para pequenos e grandes empreendimentos.

A alocação de áreas específicas para reserva legal é um tema complexo, cheio de “poréms”, variando radicalmente, dependendo de prioritariamente duas variáveis: bioma e localização da propriedade.

Para iniciar esta discussão, primeiramente, vou apresentar rapidamento o conceito de reserva legal, conforme previsto na lei 12.651 de 2012

“área localizada no interior de uma propriedade ou posse rural, delimitada nos termos do art. 12, com a função de assegurar o uso econômico de modo sustentável dos recursos naturais do imóvel rural, auxiliar a conservação e a reabilitação dos processos ecológicos e promover a conservação da biodiversidade, bem como o abrigo e a proteção de fauna silvestre e da flora nativa”;

Atualmente, o cálculo de reserva legal, deve se considerar dois casos:

Propriedade ou posse rural na Amazônia Legal

• Área de Florestas: 80% da área da propriedade;
• Área de Cerrados: 35% da área da propriedade;
• Área de Campos Gerais: 20% da área da propriedade;

Propriedade em outras regiões do país

• 20% da área da propriedade;

Existem outros detalhes importantes:

• Atualmente é possível alocar a reserva legal de uma propriedade A, na propriedade B, desde que estejam no mesmo bioma;
• No caso de Reserva Legal, localizada no Cerrado, dentro da Amazônia Legal, apenas 15% desta área pode ser alocada em outra propriedade;

Automatizando o cálculo

Ao utilizar o Geoadmin, ao cadastrar uma nova propriedade, realizamos uma série de análises sobre o perímetro da mesma. Descobrimos, por exemplo:

• O bioma onde a propriedade está localizada;
• Se a propriedade está localizada na Amazônia Legal;
• Número de módulos fiscais da propriedade e classificação de tamanho;
• Área da propriedade;
• Perímetro da propriedade;

De posse destas informações, determinamos qual é a porcentagem legal exigida para aquela propriedade, derivando os seguintes dados:

• Área de Reserva Exigida;
• Percentual de Reserva Exigida;

Todos os cálculos que involvem a interseção entre o perímetro da propriedade, consideram, caso ela esteja na divisa entre dois biomas, por exemplo, a maior porcentagem de interseção. Exemplo: caso a propriedade esteja entre o Cerrado e a Amazônia, mas está com um percentual de área maior dentro da Amazônia, consideramos que o bioma predominante é a Amazônia.

Permitindo a alocação de Reserva em outras propriedades

Dentro do Geoadmin é possível alocar reservas legais de uma propriedade em outra, seguindo o permitido pela lei (lembramos que caso queira-se alocar a RL de propriedade A em propriedade B, a propriedade B ainda deve ter sua reserva legal sem sobreposição com outras reservas legais).

É bastante comum, principalmente em empreendimentos, a compra de propriedades fora da área diretamente afetada, para a alocação de reservas.

Dentro do sistema, isto pode ser feito através do menu “Reservas Legais” ou “Alocação de Reservas”.

O Geoadmin cuida de forma transparente dos percentuais e da área alocada, atualizando corretamente:

• Área de Reserva Alocada;
• Percentual de Reserva Alocado;

Uma propriedade está correta, do ponto de vista legal, quando a área de reserva alocada é maior ou igual do que a Área de Reserva Exigida. Neste ponto, atualizamos nosso Dashboard, para mostrar aos gestores que aquela propriedade está com sua área de Reserva Legal completa.

Registre-se

Convido você a se [registrar] no Geoadmin e gerenciar suas Reservas Legais de forma fácil e transparente. Este módulo permitirá a gestão automatizada deste requisito legal – evitando possíveis problemas na regularidade de suas propriedades.

Estamos contratanto pessoal!

No momento estamos procurando dois estagiários, para áreas diferentes.

Caso você se interesse por qualquer uma das vagas, por gentileza, envie nos envie um email com seu curriculum vitae.

Ambas as vagas são presenciais e estamos localizados na bela cidade de Uberlândia – MG, bem pertinho da Universidade Federal.

Geoprocessamento e Suporte

Atividades:

O Geoadmin é ofertado como SaaS (Software como Serviço) e precisa de um estagiário com conhecimento em geoprocessamento, para desenvolvimento de atividades de suporte técnico a clientes.

Entre as atividades relacionadas, estão: atendimento de chamados via email, relativos dúvidas de clientes, auxílio na conversão de dados geográficos para entrada no sistema e produção de documentação técnica.

Perfil do Candidato:

Essencial:

• Cursando Geografia, Engenharia Ambiental, Agronomia,
  ou correlatos;
• Conhecimentos de informática e pacote Office;
• Conhecimentos de cartografia, sensoriamento remoto
  e geoprocessamento;
• Organização, excelente comunicação;

Desejável

• Conhecimentos em pacotes de software GIS,
  como: QGIS, ArcGIS, entre outros.

Informações:

Salário: R$400,00
Benefícios: Vale Transporte
Horário de Trabalho: 4h/dia flexíveis
Local de Trabalho: Bairro Santa Mônica, Uberlândia – MG

==Por favor, enviar currículos para: admin@geoadmin.com.br==

---

Desenvolvimento de Sistemas e Suporte

Atividades:

O Geoadmin é ofertado como SaaS (Software como Serviço) e precisa de um estagiário em desenvolvimento de software.

O estagiário será responsável por auxiliar a construir o sistema Geoadmin, trabalhando diretamente com clientes, pedidos de suporte, correção de bugs e desenvolvimento de novas funcionalidades – tanto de front-end como de back-end.

Perfil do Candidato:

Essencial:

• Cursando Ciências da Computação ou Sistemas de Informação;
• Lógica de programação;
• Conhecimento intermediário de Python;
• Organização, excelente comunicação;

Desejável

• git;
• Django;
• REST;

Informações:

Salário: R$400,00
Benefícios: Vale Transporte
Horário de Trabalho: 4h/dia flexíveis
Local de Trabalho: Bairro Santa Mônica, Uberlândia – MG

==Por favor, enviar currículos para: admin@geoadmin.com.br==

Você, desenvolvedor, já se deparou com cenários específicos em que você precisa controlar um fluxo de informações, mas, suportando diversos status, com diversos efeitos colaterais diferentes, entre cada mudança desses status?

Criar e manter este tipo de estrutura, manualmente, é bem complicado. Formalmente, este tipo de estrutura é chamada de máquina de estado finita ou finite state machines e para os íntimos, FSM.

Inspirados em outros pacotes disponíveis para o Django, construímos nosso próprio gerenciador de máquinas de estados. Este é mais um pacote open-source que disponibilizamos para a comunidade.

Aplicações das FSM

As aplicações das FSMs são diversas. Elas podem controlar como compoenentes internos de uma aplicação reagem a estímulos externos (usuário informa determinada informação) ou mesmo serem editadas pelo próprio usuário. Um exemplo disso são os famigerados BPM (Bussiness Process Management**) onde os próprios usuários definem até certo ponto, o fluxo da informação e por quais verificações esta deve passar antes de permitir a troca de um estado para outro.

Outro exemplo interessante é que algumas AIs são escritas usando os conceitos de FSM para determinar comportamentos de seus agentes, portanto, te garanto, FSMs são bastante flexíveis.

Na realidade, a ideia desta aplicação Django surgiu para atender uma demanda, onde os usuários mais graduados, deveriam poder escolher como a informação fluiria numa aplicação geográfica.

Instalação

Para instalar este pacote é bem simples e você pode usar o pip:

pip install django-workflow-fsm

Agora adicione este pacote ao seu INSTALLED_APPS:

INSTALLED_APPS = (
    # outras apps,
    'workflow',
    # outras apps,
)

Execute suas migrações com ./manage.py migrate

Getting Started

Terminado isto, você precisa definir qual é o modelo que você deseja controlar o status. Basta você herdar de um MixIn para obter a funcionalidade de máquina de status:

# models.py
class Projeto(StateControllerMixIn):
    nome = models.CharField(max_length=128)

Pronto. A configuração básica está pronta!

Depois disso, com toda a certeza, você deve querer editar quais status e como a informação flui entre estes status. Isto é bem fácil.

Nós controlamos o fluxo de informações utilizando três modelos:

• StateMachine;
• State
• Transition;

Vamos construir isso em um passo a passo rápido:

# shell ou fixture ou migração de dados
status_aberto = State.objects.create(code='aberto')
status_em_andamento = State.objects.create(code='em-andamento')
status_fechado = State.objects.create(code='fechado')

# nossos status estão criados. Vamos criar nossa máquina de estado

fsm = StateMachine.objects.create(name='projetos-simples', initial_state=status_aberto)
# na linha acima definimos nossa máquina e o status inicial dela, aberto.

# agora vamos definir as transicoes
aberto_andamento = Transition.objects.create(name='iniciando-projeto',
    machine=fsm,
    from_state=status_aberto,
    to_state=status_em_andamento)

andamento_fechado = Transition.objects.create(name='finalizando-projeto',
    machine=fsm,
    from_state=status_em_andamento,
    to_state=status_fechado)

Agora que nossas transições estão prontas, você pode definir qualquer projeto, com diferentes tipos de máquinas de estado, basta escolher a máquina de estado apropriada, veja só:

projeto = Projeto()
projeto.nome = 'projeto legal'
projeto.save(state_machine=fsm)

Neste momento, todas as ações da máquina de estado estão disponíveis através do mixin que você herdou na construção do modelo Projeto.

Exemplo:

projeto.current_state
# imprime "aberto"
projeto.next
# imprime "em andamento"
projeto.change_to(state_em_andamento)
# projeto será enviado para o estado "em andamento"
projeto.next
# imprime 'fechado'

Não é só isso, existem diversos ganchos que você pode usar, como tarefas específicas a serem disparadas e ações, nas quais você pode associar a um estado, para indicar que esta ação está disponível. Exemplo: no status em andamento do projeto, vocẽ pode criar comentários e apenas neste estado. Portanto, você pode criar uma Action e associá-la ao estado em-andamento.

No seu código, vocẽ pode checar qual action está disponível e renderizar o template como você achar melhor.

Outras coisas legais:

• Você pode associar permissões a cada estado, ou seja, apenas usuários com determinadas permissões podem trocar o estado da máquina;
• Você pode associar tasks (ou tarefas) que serão executadas quando um estado da máquina é alterado. Por exemplo, quando a máquina de estado mudar de estado, quero disparar um email para um usuário, informando do ocorrido. Você pode criar isso como uma Task e associar esta task a transição específica.
• Suporte para tarefas assíncronas. Por padrão, as tarefas são executadas usando o Celery, que é uma dependência do projeto. Caso você não queira executar estas tarefas de forma assícrona, basta desabilitar o Celery.
• Suporte completo para API REST, usando django-rest-framework

Repositório

Disponível no Github: https://github.com/sigma-geosistemas/django-workflow

Roadmap

• Suporte completo para tarefas assíncronas e síncronas (hoje só suportamos um modo, queriamos suportar os dois);
• Melhorar a infraestrutura de testes;
• Melhor/criar um help/ajuda/getting started;
• Outras coisitas;

Este é um pacote bem completo para gestão de máquinas de estado. Caso você tenha interesse, dê uma conferida. Estamos a disposição!