Django Topology

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á.

Django TileStache

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

Django Workflow

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!

Integrando o Django com o AD Microsoft

Em um projeto novo da SIGMA, nos foi solicitado que utilizássemos
os usuários registrados no Active Directory do cliente, significando
que teríamos de integrar toda a funcionalidade de login do nosso projeto
Django com este camarada.

Existem diversas razões para esta integração, principalmente no nosso
caso, em que o cliente final é uma grande empresa, com toda uma infraestrutura
de Tecnologia da Informação bastante sólida e madura.

Entre estas razões, se encontram, em ordem de prioridade:

  1. Cliente não quer mais um usuário/senha para usar um sistema especialista;
  2. Equipe de TI não quer gerenciar os cadastros dos usuários em mais um sistema;
  3. Economia no desenvolvimento, de tempo e dinheiro;

Como funciona?

O Django, como um framework, já possui toda um maquinário importante para
criação e manutenção de permissões e grupos. Mas existe uma “pegadinha”:
o usuário em questão precisa existir no banco de dados que estamos usando.

Isto porque as permissões e grupos estão armazenadas em um banco de dados
relacional e existem relações com chaves estrangeiras entre usuários, permissões
e grupos.

O fluxo mais simples, portanto é:

  1. Usuário se autentica com a senha do Active Directory;
  2. Usuário está inativo no AD? Caso esteja, impeça o login e inative o usuário local;
  3. Usuário não está inativo, confira a senha;
  4. Sistema confere se o usuário já existe na base local;
  5. Caso ele já exista, ok, não faça mais nada;
  6. Caso ele não exista, copie os dados do usuário e crie um novo usuário na base local;
  7. Associe permissões/grupos;
  8. Vitória;

Seguindo este fluxo, todos os componentes do Django continuam a funcionar e não
precisamos criar permissões remotas no AD (ou LDAP) o que tornaria tudo
mais complicado de administrar (pense nas migrações do Django).

Outro ponto importante, delimitador deste fluxo, é a necessidade das sessões HTTP
no Django. Sem existir um usuário na base, não conseguiremos manter as sessões. Teríamos
de adaptar também o componente que registra e valida as sessões ativas.

Portanto esta arquitetura de cópia de usuários é a mais comum para integração
em bases de usuários “remotas” (este fluxo também é usado em pacotes que realizam
autenticação e integração com outros provedores de login, como OAuth2, por exemplo).

Como realizar a integração?

Felizmente, o Django é um projeto bastante modular. Neste caso em específico,
o Django aceita a configuração de settings de autenticação, permitindo
inclusive a autenticação em múltiplos backends, em cascata. Caso a autenticação
do usuário não funcione em um backend, ele tenta no próximo.

A arquitetura do Django facilitou bastante nossa vida neste sentido.

Quais são os passos:

Configurar o AUTHENTICATION_BACKENDS em seus settings.py

Desenvolver ou reutilizar um pacote open-source que já faz a conexão
e validação do usuário no Active Directory. No nosso caso, utilizamos o
django-python3-ldap.

Configurar as variáveis do django-python3-ldap:

# settings.py
LDAP_AUTH_USER_FIELDS = {
  "username": "uid",
  "first_name": "givenName",
  "last_name": "sn",
  "email": "mail",
}
LDAP_AUTH_USER_LOOKUP_FIELDS = ("username",)
LDAP_AUTH_CLEAN_USER_DATA = "django_python3_ldap.utils.clean_user_data"
LDAP_AUTH_SYNC_USER_RELATIONS = "jango_python3_ldap.utils.sync_user_relation"
"  LDAP_AUTH_FORMAT_SEARCH_FILTERS = "django_python3_ldap.utils.format_search_filters"
# Atenção neste ponto, pois ele é necessário para funcionar com o AD
LDAP_AUTH_FORMAT_USERNAME = "django_python3_ldap.utils.format_username_active_directory"```

Para a url indique conforme abaixo substituindo <ip_ou_dominio>
por seu ip ou dominio:

# settings.py
LDAP_AUTH_URL='ldap://<ip_ou_dominio>:389'

Utilize o comando dsquery user no ms-dos para obter a seguinte informação informação:

C:\Users\csantos>dsquery user
"CN=Claudio Santos,CN=Users,DC=server,DC=local"
"CN=Guest,CN=Users,DC=server,DC=local"

Utilize os três critérios de pesquisa, resultando em: LDAP_AUTH_SEARCH_BASE = 'CN=Users,DC=server,DC=local'

Comumente temos dois tipos de usuários: InetOrgPerson ou Users. Nós utilizamos o Users,
configurando LDAP_AUTH_OBJECT_CLASS = 'Users'

Configure este settings com uma variável que podemos pegar na
tela de criação de usuário no campo em destaque na imagem,
ela representa o Pre-Windows 2000 Domain Name do Active Directory:

attribute-editor-uid

# settings.py
LDAP_AUTH_ACTIVE_DIRECTORY_DOMAIN = 'SERVER'

Por fim vá em Active Directory Users and Computer, vá na pasta Users,
em seguida, clique com o botão direito, propriedades e por fim na aba Atributte Editor
informe o login do usuário no atributo uid, como mostrado na imagem abaixo;

attribute-editor-uid

Conclusões

Não vou discorrer aqui sobre os benefícios técnicos de usar open-source ou
coisa do tipo, mas sim dos benefícios gerados por uma integração deste nível.

As vantagens auferidas tem um profundo impacto psicológico sobre o usuário final
e sobre o retorno sobre investimento.

Em primeiro lugar, o sistema parece ter sido construído e fazer parte de fato
de toda a organização. O usuário não tem a impressão de sair de seu ambiente tecnológico,
confortável e seguro, para trabalhar em um sistema externo.

Como segundo ponto, o usuário tem uma barreira menor para utilizar o sistema.
A adoção de novos sistemas em organizações grandes sempre foi e sempre será
uma dificuldade, pelo próprio fator humano. Como a barreria de início é menor,
maior será a adoção dos usuários.

Em terceiro lugar, mas consequência do segundo ponto, quanto maior a adoção
dos usuários, maior o impacto que o novo sistema terá na organização, trazendo
um retorno maior para os stakeholders do projeto.

Spatialite Ubuntu 16

A biblioteca e o projeto spatialite são bastante especiais. Ela permite que você use um banco de dados SQLite como repositório de dados espaciais, com várias tabelas e relações.

Ela é bastante poderosa neste sentido, pois facilita que usuários GIS armazenem e compartilhem seus dados de forma mais simples, ao invés de enviar um monte de shapefiles para cima e para baixo.

No nosso caso, o problemas são com o Django, não com a biblioteca em si. Devido a algumas mudanças, o Django não consegue rodar, usando ela.

Bem, de acordo com a nova versão do Django e da SpatiaLite, algumas coisas mudaram de lugar e nem sempre o Django consegue encontrar a biblioteca.

Se vocẽ ver um erro do tipo:

Unable to load the SpatiaLite library extension “libspatialite.so.7” because: /usr/lib/x86_64-linux-gnu/libspatialite.so.7: undefined symbol:
sqlite3_spatialite_init

você encontrou o mesmo problema que nós.

Isto foi experimentado na versão do Ubuntu 16.04 e provavelmente afeta a todos os derivados (no nosso caso, afetou o Mint).

A resolução é simples. Instale algumas coisas e defina uma variável de ambiente:

Instale:

sudo apt-get install libspatialite3-mod-spatialite

Configure sua variável de ambiente:

echo SPATIALITE_LIBRARY_PATH="mod_spatialite" >> ~/.bashrc

Reinicie seu shell para que ele possa ler a configuração (ou dê um source no mesmo, tanto faz :D).

No Django, configure:

SPATIALITE_LIBRARY_PATH = 'mod_spatialite'

E aí, tiveram problemas com essa atualização?

Abraços

A biblioteca e o projeto spatialite são bastante especiais. Ela permite que você use um banco de dados SQLite como repositório de dados espaciais, com várias tabelas e relações. Ela é bastante poderosa neste sentido, pois facilita que usuários GIS armazenem e compartilhem seus dados de forma mais simples, ao invés de enviar um monte