Blog Geo.NET Geoprocessamento, SIG e Sensoriamento Remoto

Boa noite pessoal,

Me desculpem pela demora em postar coisas novas no blog. Não esqueço deste espaço não, mas o tempo, continua difícil.

Hoje quero falar um pouco sobre o GeoDjango, um framework MVC (Model, View, Controller) - na verdade, MTV (Model, Template, View) para programarmos aplicações web com grande agilidade.

O lema do framework é The Web Framework for Perfectionist, ou seja: o framework web para perfeccionistas. Parece bom né?

Quais são as vantagens de se ter um framework deste tipo (MVC/MTV)?

• Código de qualidade;
• Aplicações prontas altamente configuráveis;
• Aplicação do princípio DRY - Don't Repeat Yourself - coisa que na web, é bastante comum;
• Total separação de responsabilidades: os modelos conversam com os bancos de dados, os templates desenham nossas páginas e as views representam a camada de negócios - ou seja: código (re)usável;
• Entre outras;

O MTV/MVC é apenas uma forma de se trabalhar/arquitetar uma solução. Este tipo de desenho de solução se encaixa muito bem para desenvolvimento web, pelos motivos acima. É muito menos trabalho, com alto reuso de código - ou seja, um ganho de produtividade tremendo para quem desenvolve e aumento da qualidade para os usuários.

Existem diversos frameworks deste tipo por aí, muitos deles são bons e na verdade conheço dois: Django/GeoDjango e ASP.MVC. Não quero comparar os dois, pois são classes de softwares diferentes, ambos muito bons e cada um com suas particularidades. O GeoDjango é muito atrativo pelo fato de trabalhar nativamente com vários bancos de dados, inclusive com PostGIS e outros bancos de dados espaciais menos conhecidos (MySql Spatial, Spatial Lite - por exemplo) e de conter pacotes específicos para o desenvolvimento de aplicações SIG.

O que precisamos para brincar com o tal do GeoDjango/Django?

Bem, o Django, projeto pai, que contém o código do GeoDjango é feito todo em Python. Novamente, uma linguagem fácil, tranquila de se aprender e muito flexível. Web e flexibilidade combinam. É tudo Python. Até os templates contém código Python, da mesma maneira que código .asp pode conter código C#.

Pré-requisitos (sempre existem, não?):

• Python 2.5 ou maior;
• Django 1.x;
• GeOS;
• PROJ;
• GDAL;

Para os que desejam utilizar o banco de dados PostgreSQL/PostGIS (altamente recomendado!):

• pyscopg2;

Pode parecer muita coisa, mas não é. Você precisa das bilbiotecas e os python bindings para fazer toda essa máquina de guerra funcionar. Uma dica: quem usa/usará PostgreSQL já tem o GeOS instalado (que é o mais complicado de obter/compilar). As outras são facéis de se arrumar e configurar.

Chega de papo. O que o Django/GeoDjango pode fazer por mim? Vamos à uma demonstração de código dos models espaciais:

from django.contrib.gis.db import models

# note que aqui herdamos em nossa classe
# a classe Models. Ela contém toda a funcionalidade que precisamos.
class Setor(models.Model):
    nome_setor = models.CharField(max_length=100,unique=True)
    poligono_setor = models.PolygonField(srid=29192)

    objects = models.GeoManager()

class Bairro(models.Model):
    nome_bairro = models.CharField(max_length=100,unique=True)
    setor = models.ForeignKey(Setor)
    poligono_bairro = models.PolygonField(srid=29192)

    # vamos dizer ao admin do python que usaremos mapas
    # para editar o poligono_bairro
    objects = models.GeoManager()

Só isso? Só isso. O Django já sabe o que fazer com nossos modelos. Note que  não definimos de forma explícita uma chave primária, mas podemos caso precisarmos. O Django dá suporte para diversos tipos de dados, incluindo imagens, arquivos, datas, entre outros e suporta herança entre modelos. Isso significa que podemos economizar muito código utilizando os simples conceitos da programação orientada à objetos.

Todos os modelos devem ter tabelas no banco de dados que correspondam à ele, com exceção do caso de modelos abstratos, os quais não possuem tabela nos bancos de dados. Eles servem basicamente para usarmos as funcionalidades da OOP.

from django.contrib.gis.db import models

class TipoLogradouro(models.Model)
    descricao_tipo_logradouro = models.CharField(max_length=30)

class ResultadoGeocodificacao(models.Model):
    tipo_logradouro = models.ForeignKey(TipoLogradouro)
    nome_logradouro = models.CharField(max_length=100)
    numero = models.Integer()
    # se não especificarmos o srid, o default é WGS84
    ponto_geocodificado = models.PointField()

    objects = models.GeoManager()

    class Meta:
        abstract = True

class AcidenteGeocodificado(models.Model,ResultadoGeocodificacao):
    numero_feridos = models.IntegerField()
    numero_veiculos = models.IntegerField()

A única diferença entre o primeiro e o segundo exemplo é a adição da classe interna Meta, em ResultadoGeocodificacao, com o atributo abstract = True. Esta única linha diz ao Django que ele não deve criar uma tabela correspondente para ResultadoGeocodificacao, mas, AcidenteGeocodificado irá herdar toda informação de ResultadoGeocodificado e terá sua própria tabela no banco de dados, com todos os campos especificados em ResultadoGeocodificado e AcidenteGeocodificado. Divertido não?

Lembram dos nossos posts sobre a administração pública e modelos de dados? Quero continuar a série, terminar a modelagem de dados (que é bastante simples) e iniciar no desenvolvimento desta aplicação em GeoDjango.

Django, o poderoso framework!

O que acharam do GeoDjango/Django?

Um abraço,

George R. C. Silva