GeoDjango and PostGIS

Olá, daqui é o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 1 de 15. Já tentaste calcular a distância entre dois pontos de latitude e longitude usando uma query SQL normal? Geralmente, acabas por escrever um bloco enorme e frágil de trigonometria só para descobrir qual é o café mais próximo. As bases de dados standard simplesmente não entendem o espaço físico. Resolver esta lacuna de dados é exatamente o que vamos abordar hoje em O Poder dos Web Frameworks Espaciais. As pessoas costumam pensar que armazenar dados geográficos significa apenas adicionar duas colunas decimais a uma tabela da base de dados, uma para latitude e outra para longitude. Isto é um equívoco comum. Se estiveres a construir um sistema de routing para entrega de comida e precisares de encontrar o restaurante mais próximo de um cliente, uma base de dados standard trata essas coordenadas como números de floating-point arbitrários. Ela não sabe que a Terra é uma esfera. Não consegue calcular limites, interseções ou distâncias do mundo real de forma eficiente. És obrigado a carregar milhares de registos para a memória da tua aplicação e a fazer os cálculos tu mesmo. É aqui que entra uma base de dados espacial. O PostGIS é uma extensão espacial para a base de dados PostgreSQL. Muda fundamentalmente a forma como os dados são armazenados. Em vez de duas colunas numéricas separadas, armazenas um único objeto de geometria ou geografia. Uma base de dados espacial entende nativamente a matemática do mundo físico. Sabe o que é um ponto, uma linha e um polígono. Se quiseres encontrar todos os restaurantes num raio de dois quilómetros de um utilizador, o PostGIS usa indexes espaciais especializados para encontrar a resposta instantaneamente ao nível da base de dados. Mas uma base de dados inteligente é apenas metade da solução. Ainda precisas de ligar essa lógica espacial à tua aplicação web. Isto leva-nos ao GeoDjango. O GeoDjango é um framework geográfico de classe mundial integrado diretamente no Django. Atua como a ponte entre a tua base de dados espacial e a lógica da tua aplicação. O GeoDjango estende o Object-Relational Mapper standard do Django para que possa entender geometrias do PostGIS. Interages com dados geográficos exatamente como interages com models normais da base de dados. Em vez de escreveres queries SQL espaciais raw, usas Python. Podes filtrar os resultados da base de dados com base em relações espaciais, como verificar se o polígono da zona de entrega de um restaurante contém um ponto de endereço específico do utilizador. O GeoDjango traduz o teu código Python para as queries PostGIS corretas. Até inclui map widgets para o painel de administração do Django, para que possas criar e modificar dados geográficos visualmente, logo à partida. Juntos, o PostGIS e o GeoDjango formam uma stack incrivelmente capaz. O PostGIS lida com o trabalho matemático pesado na storage layer, e o GeoDjango fornece a interface Python limpa para servir esses dados aos teus utilizadores. Paras de lutar contra trigonometria complexa e começas a construir features reais location-aware. Aqui está o ponto chave. O verdadeiro poder de um framework espacial não está apenas em desenhar linhas num web map. Está em transferir a matemática espacial complexa completamente para fora do código da tua aplicação e para um database engine construído especificamente para entender geometria. Se estás a achar estes deep dives úteis, podes apoiar o programa procurando por DevStoriesEU no Patreon. Por hoje é tudo. Obrigado por ouvires — vai construir algo fixe.

Olá, daqui fala o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 2 de 15. O caminho mais curto entre dois pontos na Terra não é uma linha reta, é uma curva. Se a tua base de dados trata a longitude e a latitude como uma grelha X e Y comum, as tuas queries de distância vão estar completamente erradas. Corrigir isto exige perceber a diferença entre os data types Geometry e Geography do PostGIS. Por defeito, as bases de dados espaciais operam num plano bidimensional. Este é o tipo Geometry. Usa matemática cartesiana standard. Se quiseres encontrar a distância entre dois pontos, a base de dados essencialmente traça uma linha reta e aplica o teorema de Pitágoras. Esta abordagem é incrivelmente rápida e altamente precisa para dados locais. Se estiveres a mapear um quarteirão, a traçar as paredes de um edifício, ou a rastrear o limite exato de um pequeno parque, a curvatura da Terra é insignificante. Um mapa plano funciona perfeitamente. Os developers assumem frequentemente que podem usar o tipo Geometry para tudo. Guardam coordenadas GPS globais, que são graus de longitude e latitude, dentro de uma coluna Geometry plana. Quando pedem à base de dados para calcular uma distância, ela devolve um número sem sentido em graus, em vez de metros ou milhas. Para obteres distâncias do mundo real com o tipo Geometry em grandes áreas, tens de traduzir continuamente os teus dados para projeções de mapas específicas e localizadas. É exatamente por isto que o PostGIS oferece o tipo Geography. O tipo Geography modela a Terra como uma esfera. Especificamente, usa nativamente o sistema de referência espacial WGS84. Quando guardas coordenadas numa coluna Geography, a base de dados percebe que a superfície é curva. Quando lhe pedes uma distância, não desenha uma linha plana. Calcula uma rota de círculo máximo. Pensa em medir uma rota de voo de Nova Iorque para Londres. Se usares o tipo Geometry num mapa plano standard sem projeção, a base de dados calcula uma linha reta a cortar diretamente a grelha. Se usares o tipo Geography, a base de dados calcula a verdadeira distância mais curta à volta da curva da Terra, traçando o círculo máximo sobre o Atlântico. Melhor ainda, o tipo Geography devolve esta distância em metros automaticamente. Evitas completamente a necessidade de seres tu a gerir projeções de mapas complexas. Aqui está o ponto-chave. Podes concluir que Geography é o tipo superior e que deve substituir Geometry por completo. Isso é falso. Calcular distâncias numa esfera requer trigonometria pesada. Exige significativamente mais poder de processamento do que a matemática de plano liso, tornando as operações em tipos Geography mais lentas. Além disso, o PostGIS suporta muito menos funções espaciais para Geography do que para Geometry. Muitas operações geométricas avançadas simplesmente não se traduzem para a matemática esférica. A tua escolha depende inteiramente da extensão física dos teus dados. Usa o tipo Geography quando a tua aplicação guarda pontos globalmente e precisa de distâncias precisas sem o overhead da gestão de projeções. Usa o tipo Geometry quando os teus dados estão confinados a uma região local específica, ou quando precisas da máxima performance absoluta e da suite completa de funções espaciais. O tipo que escolheres define a forma do mundo em que a tua base de dados vive. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 3 de 15. Transformar a tua base de dados standard num engine espacial requer exatamente três palavras de SQL, mas se as executares no contexto errado, a tua app Django vai falhar logo na sua primeira migration. Hoje, vamos focar-nos inteiramente no Setting Up do teu ambiente espacial. Começamos pela layer da base de dados. Já tens o PostgreSQL a correr e criaste uma base de dados vazia para o teu novo projeto. Nesta fase, essa base de dados é completamente standard. Ela só entende texto, integers, datas e tipos relacionais standard. Não tem qualquer conceito do que é uma coordenada ou uma geographic boundary. Para mudar isso, precisas de fazer enable do PostGIS. As pessoas costumam tropeçar aqui ao assumir que instalar os packages do PostGIS no seu server torna automaticamente todas as bases de dados spatially aware. Não é o caso. A extension espacial tem de ser criada dentro da base de dados específica que o teu projeto vai usar. Tens de te ligar diretamente a essa nova base de dados usando um database client ou a command line. Uma vez ligado, executas o comando para criar a extension chamada postgis. Essas três palavras de SQL transformam instantaneamente o environment. O PostgreSQL executa o comando, carregando centenas de funções espaciais e data types especializados para o teu schema. Também gera uma system table crucial que armazena os spatial reference systems, que fornecem as fórmulas matemáticas necessárias para projetar coordenadas globais num ecrã plano. Com a base de dados preparada, passas para o teu projeto Django. Fazes o bootstrap de um projeto standard e crias uma nova app. Vamos chamar a esta app world. Agora, abre o teu ficheiro de settings. São necessárias duas modificações distintas para fazer a ponte entre o Django e o PostGIS. Primeiro, localiza o teu array de installed apps. Precisas de adicionar o module chamado django dot contrib dot gis. Este module é o core do GeoDjango. Ele carrega os wrappers de Python para as bibliotecas geográficas subjacentes, fornecendo os spatial fields e as database lookups geográficas que vais usar para escrever queries mais tarde. Também fazes append da tua nova app world a esta lista para que o Django saiba fazer track dos seus models. Aqui está o ponto chave. A segunda modificação acontece no teu dictionary de configuração da base de dados. O Django encaminha todo o tráfego da base de dados através de um engine backend. Se deixares o engine configurado para o backend default de PostgreSQL, o Django vai tratar a tua base de dados espacial como uma base de dados relacional standard. Não vai saber como fazer serialize de uma shape geográfica ou fazer parse em segurança de uma query de bounding box. Tens de apontar explicitamente o engine para o backend PostGIS do GeoDjango. Mudas o valor do engine para django dot contrib dot gis dot db dot backends dot postgis. O resto do dictionary de connection permanece idêntico. Continuas a fornecer o database name, user, password, host e port exatamente como farias para um setup standard. Quando correres as tuas migrations iniciais, este novo backend assume o controlo. Ele liga-se ao PostgreSQL e verifica imediatamente a extension PostGIS. Se te esqueceste de criar a extension na base de dados, o backend vai detetar os spatial types em falta e lançar um erro. Se a extension estiver presente, a connection é bem-sucedida. Agora tens um pipeline espacial completo. O verdadeiro poder desta configuração específica é que, uma vez que o backend postgis esteja wired up, a enorme complexidade das queries de bases de dados espaciais fica completamente escondida por trás do familiar object relational mapper do Django. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 4 de 15. Tenta medir a área de implantação de um edifício usando latitude e longitude, e os teus números serão completamente inúteis. Isto porque a latitude e a longitude são apenas ângulos a partir do centro da Terra, não distâncias físicas. Para transformar esses ângulos em medidas utilizáveis, como metros ou pés, precisas de um Coordinate Reference System e de um SRID. Uma coordenada como 48 graus norte e 2 graus este é apenas um par de números brutos. Sem contexto, a tua base de dados não sabe como mapear esses números para o mundo físico. Esse contexto vem do Spatial Reference System Identifier, normalmente chamado de SRID. Um SRID é simplesmente um integer que liga os teus dados brutos de coordenadas a um modelo matemático específico da Terra. Por defeito, os geometry fields do GeoDjango usam um SRID de 4326. Este integer representa o sistema de coordenadas WGS84. É o modelo standard usado pelos satélites GPS e pela maioria das web mapping libraries. Armazena dados usando graus de latitude e longitude. O WGS84 é excelente para localizar pontos em qualquer parte do globo. No entanto, é um sistema geográfico, o que significa que modela a Terra como uma forma tridimensional. Aqui está o ponto chave. Não podes calcular com precisão distâncias ou áreas planas usando graus. A distância física entre duas linhas de longitude diminui à medida que te moves do equador em direção aos polos. Se tentares encontrar todos os cafés a 500 metros de um ponto usando o SRID 4326, a base de dados tem de realizar matemática esférica pesada on the fly, o que é lento e muitas vezes impreciso. Para resolver isto, usas projected coordinate systems. Um projected system achata matematicamente uma porção específica da Terra curva numa grelha bidimensional. Assim que a área é achatada, as coordenadas mudam de ângulos para unidades de comprimento standard, como metros ou pés. Isto torna os cálculos de distância rápidos e precisos usando geometria básica. A tua escolha de SRID depende inteiramente do scope da tua aplicação. Se estiveres a construir um sistema global de rastreio de voos, guardas os teus dados usando WGS84 e SRID 4326. Os teus pontos abrangem o mundo inteiro, por isso precisas de um sistema global, mesmo que os cálculos de distância sejam um pouco mais complexos. Se estiveres a construir uma aplicação de planeamento urbano local para medir limites exatos de propriedades, usar o WGS84 é um erro. Em vez disso, atribuis um projected coordinate system local ao teu spatial field. Por exemplo, podes usar um State Plane coordinate system específico com o seu próprio SRID único. Estes sistemas locais são altamente adaptados. Eles minimizam a distorção que acontece quando achatas uma esfera, mas apenas para essa zona geográfica específica. Ao configurares os teus models no GeoDjango, defines o SRID diretamente no spatial field. Se não fizeres nada, o default é 4326. Se quiseres uma projeção localizada em metros, passas esse integer específico para a field definition. O GeoDjango depois trata toda a geometry nessa coluna de acordo com esse modelo matemático específico. O SRID correto garante que os teus cálculos de distância não fiquem distorcidos à medida que os teus dados se afastam do equador. Obrigado por ouvires. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 5 de 15. Queres adicionar dados de localização à tua aplicação, por isso podes pensar em adicionar dois float fields simples para latitude e longitude à tua database. Mas fazer isso impede-te completamente de fazer spatial queries avançadas, cálculos de distância e interseções geométricas. Para desbloquear essas capacidades, precisas de spatial types adequados, o que nos leva ao Design de Modelos Geográficos. Passar dos models standard do Django para os models do GeoDjango requer apenas uma pequena alteração nos teus imports. Em vez de ires buscar aos database models standard do Django, importas os models do módulo contrib geographic. Este módulo customizado oferece um drop-in replacement. Dá-te acesso a todos os field types standard do Django, como characters e integers, enquanto introduz de forma fluida os spatial types exatamente na mesma class definition. Imagina um cenário em que estás a construir um model WorldBorder para guardar dados de países. Defines a model class como qualquer outra. Atribuis um character field para o nome do país, um integer field para a população e um float field para a área total do território. Para lidar com a geometry real do mapa, adicionas um geographic field diretamente ao lado dos outros. Para um país, usarias um MultiPolygonField. Enquanto um PointField é perfeito para guardar um único par de coordenadas, como uma capital, um MultiPolygonField pode representar fronteiras nacionais complexas, incluindo nações com múltiplas massas de terra desconectadas ou ilhas costeiras. Ao anexares este spatial field ao teu model, estás a definir um coordinate system nos bastidores. Cada geographic field depende de um Spatial Reference System Identifier, conhecido como SRID. O SRID diz à database como projetar os números brutos das coordenadas na forma real da Terra. Se não definires explicitamente este valor, o GeoDjango assume automaticamente o SRID 4326 por default. Esse integer específico refere-se ao standard WGS84, que é exatamente o mesmo coordinate system usado pelo hardware de GPS standard. Se os teus dados de origem dependerem de uma projeção local diferente, basta passares o integer de destino para o parameter SRID diretamente na field definition. É aqui que a coisa fica interessante. Os developers familiarizados com o ORM do Django sabem que, para tornar uma column rápida de fazer query, tens de passar explicitamente uma database index flag para a field definition. Como as spatial queries são inerentemente pesadas, podes assumir que precisas de configurar manualmente indexes especializados para as tuas geometry columns. Mas não precisas. Os geographic fields no GeoDjango funcionam de maneira diferente. Eles incluem um parameter específico para spatial indexing, e o default é true. Quando corres as tuas migrations, o GeoDjango diz automaticamente à database subjacente para construir um spatial index especializado. Tens bounding box queries de alta performance e geographic intersection lookups logo out of the box, com zero configuração extra. A verdadeira força de desenhar models desta forma é que desmistifica completamente os spatial data. Um polígono enorme e complexo a representar um continente torna-se apenas mais uma property no teu object Python, pronto para ser guardado e alvo de queries juntamente com uma simples contagem populacional. Por hoje é tudo. Obrigado por ouvires — vai construir algo fixe.

Olá, daqui é o Alex do DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 6 de 15. Recebes um ficheiro espacial enorme — um ESRI Shapefile ou um GeoJSON — e precisas de saber que atributos contém. O teu primeiro instinto pode ser instalar um programa GIS pesado no desktop só para espreitar lá para dentro. Mas não precisas. O GeoDjango consegue ler estes ficheiros nativamente, diretamente na shell de Python, usando a API GDAL e OGR. Se os sistemas de informação geográfica são uma caixa de ferramentas, a Geospatial Data Abstraction Library é o tradutor universal. Tecnicamente, a GDAL lida com dados raster, como imagens de satélite, enquanto a sua parceira OGR lida com dados vetoriais, como pontos, linhas e polígonos. O GeoDjango inclui um wrapper Pythonic para a biblioteca OGR, dando-te uma forma direta de inspecionar praticamente qualquer formato de ficheiro vetorial do planeta. Imagina que descarregaste um shapefile que contém as fronteiras de todos os países do mundo. Antes de escreveres um script para importar estes dados, precisas de saber exatamente como estão estruturados. Começas por importar o objeto DataSource do módulo GDAL do GeoDjango. Crias uma nova data source passando-lhe o file path do teu shapefile. Este objeto agora representa todo o teu dataset espacial descarregado. Uma data source organiza a sua informação espacial em layers. Podes pedir à data source a contagem das suas layers. Um ESRI Shapefile tradicionalmente contém apenas uma layer, mas formatos como GeoPackages podem conter dezenas. Recuperas essa primeira layer usando o seu index, exatamente como se estivesses a extrair um item de uma list standard de Python. Aqui está o ponto-chave. O objeto layer é onde a verdadeira introspeção acontece. Atua como um container para registos espaciais individuais, aos quais a API chama features. Podes pedir à layer que devolva a sua contagem total de features. Para o nosso ficheiro de fronteiras mundiais, a contagem deve corresponder aproximadamente ao número de países na Terra. Também podes pedir à layer o seu geometry type. Isto confirma se os dados consistem em pontos, linhas ou polígonos. Para fronteiras de países, o tipo normalmente será devolvido como MultiPolygon. A seguir, precisas de saber que metadata está associada a essas shapes. Podes consultar a layer para obter os seus fields. Isto devolve uma list de strings que representam os nomes das colunas de atributos. Podes encontrar nomes correspondentes a um código de país interno, um nome comum e uma contagem de população. Podes até descer mais um nível. Ao aceder a uma feature individual da layer pelo seu index, podes inspecionar um único país. Podes consultar essa feature específica para obter o valor do seu field de nome comum. Também podes aceder ao objeto geometry específico dessa feature e pedir-lhe que devolva as suas coordenadas como well-known text ou GeoJSON. Agora mapeaste exatamente que shapes o ficheiro contém, os nomes dos seus atributos e a estrutura dos seus registos. Fizeste tudo isto puramente através de Python, sem escrever um script de importação para a base de dados ou depender de software de visualização externo. O wrapper GDAL transforma a tua shell de Python standard numa lente exploratória para dados espaciais, permitindo-te validar ficheiros externos antes que um único registo toque na tua base de dados. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 7 de 15. Importar milhares de polígonos geográficos e os seus metadados manualmente pode demorar dias. Os teus ficheiros de origem têm nomes de colunas enigmáticos e tipos incompatíveis, mas a tua base de dados exige uma estrutura rígida. A solução é o utilitário LayerMapping do GeoDjango, que lida com todo este processo de ingestão com exatamente um dictionary. Ao trabalhar com dados espaciais, recebes frequentemente ficheiros vetoriais como os Shapefiles da ESRI. Estes ficheiros contêm tanto as formas geométricas dos locais como os dados de atributos associados a essas formas. No entanto, ficheiros externos raramente correspondem ao schema da tua base de dados. Um Shapefile pode ter uma coluna de população abreviada como POP2005 e um código de país listado como ISO2. O teu model Django impecável, vamos chamar-lhe WorldBorder, possui fields com nomes claros e tipos estritamente definidos para esses mesmos atributos. Podes sentir-te tentado a usar importações SQL manuais ou ferramentas de base de dados como o pgAdmin para enviar estes dados para o PostGIS. O LayerMapping é uma abordagem completamente diferente. É um utilitário de script Python programático. Vive diretamente no teu projeto Django, integrando ficheiros espaciais externos diretamente ao teu Object Relational Mapper. Aqui está o ponto-chave. O núcleo do LayerMapping é um dictionary Python simples. As keys deste dictionary são os nomes dos fields do teu model Django limpo. Os values são os nomes em raw string dos atributos no teu ficheiro de origem. Por exemplo, o teu dictionary mapeia o nome do field do model Django para o atributo NAME do Shapefile. Mapeia o field de população do teu model para POP2005 e o field de código ISO para ISO2. Também mapeias o field de geometria do teu model para o tipo de geometria do Shapefile, que geralmente é representado por uma string como MULTIPOLYGON. Para automatizar isto, escreves um pequeno ficheiro Python, geralmente chamado de load script. Dentro deste script, importas o teu model WorldBorder e a ferramenta LayerMapping. Defines o teu dictionary de mapping. Em seguida, crias uma nova instance do LayerMapping. Passas a esta instance três informações obrigatórias. Primeiro, o teu model Django. Em segundo lugar, o file path para o teu Shapefile de origem. Em terceiro lugar, o dictionary de mapping que acabaste de criar. Também podes fornecer arguments opcionais para controlar o comportamento de ingestão. Se os teus dados de origem já estiverem no sistema de referência espacial exato que a tua base de dados espera, podes instruir o utilitário a não realizar transformações de coordenadas. Isto evita cálculos desnecessários e acelera o import. Finalmente, chamas o method save na tua instance de LayerMapping. Quando executas este script, o utilitário assume o controlo total. Ele abre o Shapefile, itera por cada feature geográfica e usa o teu dictionary para alinhar os atributos complexos do ficheiro com os fields rígidos do teu model. Traduz automaticamente a geometria bruta para um formato que o PostGIS entende e guarda os registos na tua base de dados. Podes instruir o method save a levantar uma exception no primeiro erro que encontrar, ou podes deixá-lo executar e simplesmente fazer log de quaisquer features com problemas no teu terminal. A principal conclusão é que o LayerMapping desvincula completamente a estrutura rígida de ficheiros espaciais externos do design limpo da tua base de dados, permitindo-te ingerir datasets massivos com apenas algumas linhas de Python. Antes de terminarmos, se gostas do programa e queres ajudar-nos a continuar, podes apoiar-nos procurando por DevStoriesEU no Patreon. Por hoje é tudo. Obrigado por ouvires e continua a desenvolver!

Olá, daqui é o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 8 de 15. Podes pensar que, sempre que precisas de fazer o merge de dois polygons ou encontrar uma interseção espacial, tens de escrever uma query e esperar que a base de dados devolva uma resposta. A realidade é que podes fazer matemática espacial complexa diretamente na tua shell Python, sem nunca tocares numa ligação à base de dados. É exatamente isso que vamos cobrir hoje: a API GEOS e a geometria pythónica. Um equívoco comum com o GeoDjango é achar que o PostGIS trata de todo o trabalho pesado espacial. Embora o PostGIS seja incrivelmente poderoso, a API GEOS permite-te executar operações geométricas inteiramente em memória local. GEOS significa Geometry Engine Open Source. É uma library C++ altamente otimizada, mas o GeoDjango dá-te um wrapper poderoso chamado objeto GEOSGeometry. Este objeto permite-te criar, manipular e analisar geometrias puramente em Python. É aqui que a coisa fica interessante. Um objeto GEOSGeometry não parece um wrapper desajeitado à volta de uma library C. Funciona exatamente como um container nativo de Python. Se tiveres uma LineString com dez pontos, podes correr a função length standard de Python para veres que tem dez coordenadas. Podes iterar sobre um Polygon com um for-loop standard para extrair os seus anéis individuais, ou usar um index para ir buscar um ponto específico de uma geometria MultiPoint. Comportam-se exatamente como as familiares lists ou tuples de coordenadas. O verdadeiro poder revela-se quando aplicas operações topológicas. Imagina que estás a construir uma aplicação de logística e tens duas zonas de entrega sobrepostas definidas como GEOS Polygons. Precisas de encontrar a área exata onde estas duas zonas se sobrepõem. Não precisas de guardar estas zonas num model e correr uma query na base de dados. Em vez disso, podes gerar a sobreposição instantaneamente em memória. Primeiro, instancias dois objetos GEOSGeometry que representam as tuas zonas de entrega. A seguir, podes simplesmente chamar o método intersection no primeiro polygon, passando o segundo polygon como argumento. Como a API é profundamente pythónica, também podes simplesmente usar o operador bitwise AND. Digitas literalmente polygon um, um ampersand, e polygon dois. Isto devolve um objeto GEOSGeometry completamente novo que representa a forma exata da sobreposição. Tens acesso a um conjunto completo destas operações espaciais. Se precisares de encontrar a área coberta pela primeira zona de entrega, mas estritamente fora da segunda, usas o método difference, ou o operador minus normal de Python. Se quiseres fazer o merge delas para uma única zona enorme, usas o método union, ou o operador bitwise OR pipe. Podes até gerar novas formas do nada. Chamar o método buffer numa geometria de ponto com um argumento de width calcula e devolve instantaneamente um polygon que representa um círculo perfeito desenhado à volta desse ponto. Como tudo depende do motor C++ subjacente, estes cálculos acontecem de forma extremamente rápida. A principal conclusão aqui é que a API GEOS dá-te um motor espacial independente em memória, permitindo-te validar geometrias, calcular buffers e encontrar interseções antes que um único byte de dados chegue à tua base de dados. É tudo por este episódio. Até à próxima!

Olá, daqui é o Alex do DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 9 de 15. Esquece escrever comparações de coordenadas gigantes. Tens a localização de um utilizador e uma zona de entrega, e precisas de saber se elas se sobrepõem. Fazer isto matematicamente significa verificar centenas de arestas de polígonos na lógica da tua aplicação. Em vez disso, o GeoDjango reduz isto completamente a uma operação de base de dados. Hoje, vamos dominar os spatial lookups. Se já usaste o Django, conheces a sintaxe de double-underscore para filtrar querysets. Adicionas algo como double-underscore exact ou double-underscore in ao nome de um campo. O GeoDjango estende exatamente esta mesma sintaxe para executar relações topológicas complexas do PostGIS. Relações topológicas são apenas regras sobre como as geometrias partilham espaço. Estão a tocar-se? Estão sobrepostas? Está uma completamente dentro da outra? O GeoDjango dá-te tipos de lookup dedicados para fazeres estas perguntas diretamente nas tuas queries do ORM. O spatial lookup mais comum e tolerante é o intersects. Se filtrares um campo de geometria com double-underscore intersects, a base de dados devolve registos onde as duas geometrias partilham qualquer porção de espaço. Podem cruzar-se, podem tocar-se numa fronteira, ou uma pode envolver completamente a outra. Desde que haja algum espaço partilhado, o intersects é avaliado como true. Muitas vezes, precisas de mais precisão do que uma simples interseção. Precisas de limites estritos. É aqui que o contains e o within entram em jogo. Os developers confundem estes dois constantemente. Aqui está a ideia principal. A diferença é puramente direcional. Se a geometria A contém a geometria B, então a geometria B está dentro da geometria A. Pensa numa caixa e num berlinde. A caixa contém o berlinde. O berlinde está dentro da caixa. Escolhes o lookup com base na geometria que está na coluna da tua base de dados e na geometria que estás a passar como argumento do filter. Considera um cenário concreto. Tens uma tabela de casas na base de dados, e cada casa tem uma point geometry que representa a sua localização. A câmara municipal acabou de lançar um novo polígono que define uma zona de inundação designada. Precisas de encontrar todas as casas que estão perfeitamente dentro dessa área de risco. Não fazes uma query à zona de inundação para ver o que ela contém. Fazes uma query às casas. Chamas o filter no model da casa, referencias o campo da point geometry, adicionas double-underscore within, e passas o polígono da zona de inundação como valor. Quando executas essa query, o Django traduz o teu lookup de double-underscore numa chamada de função nativa do PostGIS, especificamente ST_Within. O motor da base de dados avalia as geometrias usando os seus índices espaciais otimizados. Ele verifica se cada coordenada do ponto da casa está no interior do polígono da zona de inundação. Se a casa estiver exatamente na fronteira do polígono, não é considerada within. Contenção estrita significa que o interior da primeira geometria tem de estar completamente dentro do interior da segunda geometria. Se inverteres o cenário, digamos que estás a fazer uma query a uma tabela de bairros na base de dados para encontrar o que rodeia a localização específica de um utilizador, usas double-underscore contains. Filtras o campo do polígono do bairro, adicionas double-underscore contains, e passas o ponto do utilizador. A lógica é idêntica nos bastidores, mas a ordem dos argumentos espaciais passados ao PostGIS é trocada. Compreender esta lógica direcional evita falhas silenciosas e querysets vazios. Ao mapear as operações do PostGIS diretamente para keyword arguments do Django, filtras datasets espaciais gigantes de forma eficiente sem escreveres raw SQL. A geometria pela qual estás a filtrar dita sempre a direção do teu spatial lookup. Obrigado por ouvires. Até à próxima!

Olá, daqui fala o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 10 de 15. As queries de raio são o pão nosso de cada dia das aplicações baseadas em localização. Se as escreveres mal, a tua base de dados calcula a distância exata para cada linha da tua tabela, forçando um full scan massivo. Se as escreveres bem, demora milissegundos. Queries de distância de alta performance são a diferença entre uma app que responde no momento e uma que crasha sob carga. Um erro comum que os developers cometem é pensar em queries espaciais da mesma forma que pensam em matemática básica. A abordagem ingénua é calcular a distância precisa do teu ponto de destino para todos os outros pontos na base de dados, e depois filtrar tudo o que for maior que o teu raio máximo. Nunca deves fazer isto. Calcular distâncias reais numa esfera é computacionalmente pesado. Se a tua query filtrar calculando a distância primeiro, a base de dados não consegue usar os seus índices espaciais. É forçada a verificar cada linha. Para manter as queries rápidas, tens de depender de lookups baseados em índices. Antes de olhar para os lookups da base de dados, precisas de uma forma de expressar a distância de forma clara no teu código Python. O GeoDjango fornece o objeto Distance, geralmente importado simplesmente como a letra D maiúscula. Inicializas o objeto com uma unidade e um valor. Por exemplo, passar o argumento m i igual a cinco a este objeto cria uma medida de exatamente cinco milhas. Podes usar quilómetros, metros, ou até mesmo graus. Isto normaliza a medida em Python antes sequer de a query bater na base de dados. Considera um cenário onde estás a implementar uma feature que encontra todos os cafés num raio de cinco milhas do ping de GPS atual de um utilizador. Tens o ponto de localização do utilizador, e queres fazer uma query ao teu model de cafés. Podes usar o lookup de distance less-than-or-equal. Escreves um filter na query onde o teu campo de localização do café é seguido por um duplo underscore e a palavra distance, um underscore, e as letras l t e. Passas-lhe um tuple que contém o ponto do utilizador e o teu objeto distance definido para cinco milhas. Isto funciona. Traduz-se numa função da base de dados que verifica se a distância é menor ou igual a cinco milhas. Mas dependendo do teu backend espacial e de como as tuas colunas estão configuradas, este lookup ainda pode fazer mais trabalho matemático do que o estritamente necessário, ao calcular distâncias exatas antes de fazer a comparação final. Aqui está o ponto chave. Raramente precisas de saber a distância exata para filtrar um raio. Só precisas de saber se o objeto está dentro do círculo. É aqui que o lookup dwithin se torna essencial. Em vez de distance less-than-or-equal, adicionas um duplo underscore e a palavra dwithin ao teu campo de localização. Passas-lhe exatamente o mesmo ponto do utilizador e o objeto distance de cinco milhas. Nos bastidores, isto vai diretamente para a função do PostGIS ST DWithin. Esta função é altamente otimizada. Faz primeiro uma verificação rápida de bounding-box, o que utiliza perfeitamente os teus índices espaciais. Desenha um quadrado aproximado à volta do teu raio de cinco milhas e descarta imediatamente quaisquer pontos fora desse quadrado, sem fazer qualquer matemática esférica complexa. Apenas faz cálculos precisos e pesados para os poucos pontos que caem perto do limite do círculo dentro desse quadrado. Se a tabela da tua base de dados usar colunas geography em vez de colunas geometry básicas, o PostGIS lida com a curvatura da Terra automaticamente, mantendo o uso dos índices super rápido. O hábito mais valioso na programação espacial é perceber que verificar se um ponto vive dentro de uma forma é sempre mais barato do que puxar de uma fita métrica para calcular a distância exata entre eles. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui fala o Alex do DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 11 de 15. Tens uma base de dados cheia de polígonos enormes e complexos, e o teu frontend só precisa de mostrar um pin no centro de cada um. Se fores buscar esses polígonos brutos para o Python para calcular o centro, estás a arrastar megabytes de dados de coordenadas inúteis pela rede. A solução é passar essa matemática para a base de dados usando Geographic Database Functions. Existem duas formas de obter informação espacial, como a área ou um ponto central, no GeoDjango. A primeira é fazer uma query ao registo da base de dados, puxar a geometria inteira para um objeto GEOS do Python, e aceder a uma propriedade como dot area. Não faças isto a não ser que precises mesmo da geometria completa no Python. Ir buscar a fronteira de um parque nacional pode significar carregar dezenas de milhares de vértices para a memória só para calcular um único número. A segunda forma, muito mais eficiente, é dizer ao PostGIS para calcular a resposta e devolver apenas o resultado final. É aqui que as Geographic Database Functions, combinadas com o método annotate do ORM do Django, se tornam essenciais. Vejamos um cenário prático. Estás a construir uma API que lista parques nacionais. Para a list view, a aplicação cliente só precisa do nome do parque, da sua área total, e de uma única coordenada central para colocar um pin no mapa. Não precisa do complexo polígono de fronteira. No teu queryset do Django, usas o método annotate. Dizes-lhe para criar um novo atributo, talvez chamado park area, e defines que é igual à função Area a atuar na tua coluna de geometria. A seguir, crias outro atributo chamado center point, definido como igual à função Centroid nessa mesma coluna de geometria. Finalmente, restringes o output da query apenas ao nome e às tuas duas novas annotations. Quando esta query é executada, o PostGIS lê os dados de geometria brutos no disco. Executa rotinas internas altamente otimizadas para calcular a área espacial e encontrar o ponto central matemático. Depois, devolve exatamente três coisas pela rede para a tua aplicação Django: uma string de texto para o nome, um número para a área, e uma geometria de ponto único para o centro. Evitas completamente os custos de largura de banda e de memória de transferir o polígono grande. Esta estratégia aplica-se a muitas operações espaciais. Podes usar a função Transform dentro de uma annotation para converter coordenadas da projeção de armazenamento da tua base de dados diretamente para a projeção que o teu web map precisa, como Web Mercator. A base de dados trata da matemática antes sequer de o Python ver os dados. Também podes usar a função AsGeoJSON. Isto diz ao PostGIS para formatar os dados espaciais numa string de texto JSON standard diretamente na base de dados. Quando o Django o recebe, é apenas texto pronto a passar diretamente para o teu frontend, evitando completamente o overhead de serialização do Python. Também podes aplicar funções de agregação em querysets inteiros. A função Extent olha para um grupo de geometrias e devolve uma única bounding box que as cobre a todas. Se um utilizador pesquisar por todos os parques numa região específica, devolver o Extent dá-te as coordenadas exatas necessárias para fazer zoom automaticamente no mapa do frontend para encaixar todos os resultados na perfeição. Aqui está o ponto chave. A tua base de dados espacial é um motor de computação altamente especializado, não apenas um contentor de armazenamento. Mantém as tuas computações espaciais pesadas dentro do PostGIS, e move apenas as respostas calculadas pela rede para o Python. É tudo por este episódio. Até à próxima!

Olá, daqui é o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 12 de 15. As formas vetoriais são ótimas quando queres desenhar uma linha precisa à volta do limite de uma cidade ou localizar a posição de um utilizador. Mas o que acontece quando precisas de mapear algo que não tem limites rígidos, como a variação de temperatura num continente ou a altitude de uma cordilheira inteira? Não podes desenhar um polígono para cada grau de temperatura. É aqui que entram os dados raster no PostGIS. Se estás habituado a trabalhar com pontos, linhas e polígonos, os dados raster exigem uma mudança de perspetiva. Os dados raster não são compostos por formas discretas. São uma grelha contínua de pixels, exatamente como uma fotografia digital. Mas, em vez de valores de cor vermelha, verde e azul, cada pixel contém um dado numérico específico. Esse dado pode ser a precipitação, o tipo de solo ou a altitude. Toda a grelha está matematicamente ligada ao mundo real através de georreferenciação. Isto significa que a base de dados sabe exatamente onde cada pixel se encontra no mapa. No GeoDjango, lidar com estes dados envolve principalmente dois componentes: o RasterField e o objeto GDALRaster. O RasterField é o tipo de coluna da base de dados. Adicionas isto ao teu model Django da mesma forma que adicionarias um campo de geometria. Isto diz ao PostGIS para alocar espaço para os dados da grelha internamente. Mas não interages diretamente com os bytes brutos da base de dados. Quando extrais um raster da base de dados, ou antes de inserires um, usas o GDALRaster. Este é um wrapper em Python para as bibliotecas geoespaciais subjacentes. Permite-te inspecionar as propriedades do raster, como a sua escala, o seu sistema de referência de coordenadas e os valores reais dentro das suas bands. Uma band é apenas uma única layer de dados na grelha. Uma imagem normal tem três bands para a cor, mas um mapa de elevação normalmente tem apenas uma band a representar a altitude. Considera um cenário concreto. Estás a construir uma aplicação para caminhantes e tens um Digital Elevation Model de uma cordilheira. Este modelo de elevação é geralmente fornecido como um ficheiro GeoTIFF. Primeiro, defines um model Django para a tua cordilheira e dás-lhe um RasterField. Depois, no teu código Python, instancias um GDALRaster passando-lhe o caminho do ficheiro para o teu GeoTIFF. O Django carrega o ficheiro para a memória como um objeto GDALRaster. Atribuis esse objeto ao RasterField no teu model da montanha e chamas o save. O PostGIS pega nessa grelha e armazena-a. Agora, quando um caminhante faz o upload da sua rota GPS, podes fazer uma query à base de dados para descobrir exatamente em que pixel as suas coordenadas caem. Extrais o valor de elevação armazenado nesse pixel específico. Quando lês esse campo novamente da base de dados, o Django dá-te um objeto GDALRaster outra vez. Podes pedir a este objeto a sua largura, a sua altura ou a sua extensão espacial. Podes aceder aos arrays de dados brutos dos pixels diretamente em Python para realizar cálculos antes de enviar os dados para o front end da tua aplicação. Aqui está a ideia principal. Usas vetores para coisas que existem num local específico, e usas rasters para coisas que existem por toda uma área. Ao combinar ambos no PostGIS, a tua aplicação pode relacionar objetos discretos, como um trilho de caminhada, com ambientes contínuos, como a altitude real do terreno debaixo dos teus pés. Se quiseres ajudar a manter o podcast no ar, podes procurar por DevStoriesEU no Patreon — o teu apoio significa muito. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui fala o Alex da DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 13 de 15. E se precisares de saber a localização de um utilizador para lhe servires conteúdo local, mas ele não te tiver concedido permissões de GPS? O seu endereço IP de entrada contém a resposta. Isto é Geolocalização com GeoIP2. Para ser claro desde o início, a geolocalização por IP não é um lookup preciso de coordenadas como uma API de geolocalização do browser. É uma aproximação. Quando pesquisas um endereço IP, estás a consultar um dataset estático que mapeia blocos de IP atribuídos a áreas geográficas. Quase sempre obténs o país certo e, muitas vezes, a cidade certa, mas não vais encontrar a morada real do utilizador. Considera um cenário em que um visitante acede ao teu site de e-commerce. Queres redirecioná-lo automaticamente para a storefront localizada do seu país ou centrar um mapa por default na sua região, puramente com base no seu endereço IPv4 ou IPv6 de entrada. O GeoDjango fornece o objeto GeoIP2 especificamente para lidar com este lookup offline. Antes de poderes escrever qualquer lógica, precisas de ter as peças certas no lugar. Primeiro, instalas a library geoip2 de Python no teu environment. Segundo, precisas dos dados em si. O GeoIP2 depende de datasets da MaxMind, tipicamente as databases gratuitas GeoLite2 City ou Country. Fazes o download destes ficheiros, que têm uma extensão mmdb, e colocas no teu servidor. Por fim, nos teus settings do Django, defines uma variável chamada GEOIP_PATH e apontas para o diretório que contém esses ficheiros. O Django espera encontrar ficheiros com nomes específicos, como GeoLite2-City dot mmdb, nessa pasta. Com o setup concluído, usar a ferramenta requer apenas alguns passos. Importas o objeto GeoIP2 do module django contrib gis geoip2 e instancias o objeto. Extrais a string do endereço IP de entrada dos headers do teu request, e passas para um dos métodos de lookup. Se precisares apenas de uma lógica de routing mais abrangente, chamas o método country. Passas o endereço IP, e ele devolve um dictionary contendo o country code e o nome do país. Se precisares de mais granularidade para centrar um mapa, chamas o método city em vez disso. Isto devolve um dictionary mais rico, contendo o nome da cidade, a região e os valores aproximados de longitude e latitude. O método city também inclui os dados do país, por isso só precisas de fazer uma call. Se simplesmente quiseres as coordenadas para alimentar outra função, existem métodos dedicados como coords que devolvem um tuple básico de longitude e latitude. Também precisas de lidar com as falhas de forma elegante. Se passares um endereço IP inválido, ou um endereço que simplesmente não está presente na database da MaxMind, o GeoIP2 não devolve um dictionary vazio. Ele levanta uma GeoIP2Exception. Tens de envolver as tuas calls de lookup num bloco try e fornecer uma localização de fallback por default para a tua storefront quando o lookup falha. Aqui está a ideia principal. O código em si é essencialmente apenas um leitor de ficheiros otimizado. A precisão da tua geolocalização depende inteiramente da atualização da database que está no teu diretório GEOIP_PATH. As alocações de IP mudam constantemente. Se construíres um sistema de routing à volta do GeoIP2, tens de automatizar o download de novos ficheiros de database regularmente, ou os teus redirects localizados vão tornar-se incorretos de forma lenta e silenciosa. É tudo por agora. Até à próxima!

Olá, daqui é o Alex do DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 14 de 15. Testar aplicações espaciais tem um detalhe peculiar: a tua base de dados de testes automatizados precisa de instalar extensões espaciais complexas ao nível de C antes mesmo de o primeiro teste correr. Se o teu pipeline automatizado está a ir abaixo instantaneamente com erros de permissões, provavelmente é por isto. Hoje, vamos falar sobre testar aplicações espaciais. O primeiro requisito é estritamente de configuração. Quando corres os testes, o Django cria uma base de dados de testes paralela para manter os teus dados de produção seguros. Para o GeoDjango, esta base de dados de testes tem de ser espacial. Isto significa que as configurações da tua base de dados devem usar explicitamente um motor espacial, como o backend PostGIS fornecido pelo GeoDjango. Não podes usar o backend Postgres standard e simplesmente adicionar campos espaciais mais tarde. O backend espacial é o que diz ao test runner do Django para procurar e inicializar as features espaciais necessárias. Aqui está o ponto chave. O test runner standard do Django cria uma base de dados nova, corre as tuas migrations e começa a testar. Mas, para uma aplicação GeoDjango, criar uma base de dados nova não é suficiente. A base de dados também tem de carregar a extensão PostGIS. Isto não é uma tabela SQL standard. É uma extensão ao nível do sistema. Por default, o PostgreSQL restringe quem pode criar extensões por motivos de segurança. Normalmente, exige um utilizador da base de dados com privilégios de superuser. É exatamente aqui que os pipelines de continuous integration costumam falhar. Levantas um container Postgres, passas um utilizador de base de dados standard e dizes ao Django para correr os testes. O Django liga-se, tenta construir a base de dados de testes, tenta correr o comando para criar a extensão PostGIS e esbarra num erro de permissão negada. Para corrigir isto num pipeline automatizado, o utilizador da base de dados que está a correr os testes tem de ter os privilégios necessários. A abordagem mais direta num ambiente isolado e descartável é conceder ao utilizador de testes roles de superuser temporariamente. Se as tuas políticas de segurança proibirem o acesso de superuser mesmo num container temporário, tens de configurar o PostgreSQL para que o utilizador de testes específico seja um owner de confiança da base de dados de testes e tenha permissão explícita para criar a extensão PostGIS. Assim que a base de dados estiver construída, o GeoDjango precisa de saber com o que está a trabalhar. Diferentes versões do PostGIS suportam diferentes funções espaciais. Durante as operações normais, o GeoDjango faz queries à base de dados para determinar a versão do PostGIS instalada. No entanto, num ambiente de testes, podes fazer bypass a esta query definindo uma setting específica chamada PostGIS Version. Forneces isto como um tuple de três números, representando as versões major, minor e patch. Definir isto explicitamente pode acelerar a inicialização dos testes e funciona como um fail-safe caso a ligação à base de dados tenha dificuldades durante a verificação inicial da versão. Correr testes espaciais não é sobre escrever assertions diferentes. É principalmente um desafio de infraestrutura. A conclusão mais crítica é que, se o teu utilizador da base de dados de testes não conseguir criar extensões on the fly, os teus testes nunca vão sequer começar. Corrige os privilégios do teu utilizador de testes para fazer o bootstrap do PostGIS, e o resto do teu pipeline vai comportar-se exatamente como uma test suite standard do Django. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex do DEV STORIES DOT EU. GeoDjango e PostGIS, episódio 15 de 15. A tua app espacial corre perfeitamente no teu portátil. Fazes push para um servidor de produção, o tráfego dispara e, de repente, a aplicação vai abaixo silenciosamente. Sem o traceback standard do Python, apenas processos mortos. O problema é um conflito de threads nas profundezas de uma biblioteca de C. Fazer deploy de aplicações GeoDjango exige evitar exatamente esta armadilha. Fazer deploy de uma web app espacial é quase idêntico a fazer deploy de um projeto Django standard. O routing, as ligações à base de dados e a arquitetura do servidor seguem exatamente as mesmas regras. Mas o GeoDjango traz uma variável oculta. Essa variável é a Geospatial Data Abstraction Library, normalmente conhecida como GDAL. A GDAL é uma biblioteca de C enorme e altamente otimizada, que faz o trabalho pesado para formatos de dados geográficos e transformações de coordenadas. Aqui está o ponto chave: a GDAL não é thread-safe. Isto explica porque é que o teu código funciona localmente, mas crasha no servidor. O servidor de desenvolvimento local do Django processa os requests sequencialmente. Raramente desencadeia acessos concorrentes à biblioteca de C. Os servidores WSGI de produção são construídos de forma diferente. Para lidar com tráfego elevado de forma eficiente, servidores como o Apache com mod_wsgi normalmente criam múltiplas threads dentro de um único processo. O Python normalmente depende do Global Interpreter Lock para evitar que as threads colidam. No entanto, as bibliotecas de C gerem a sua própria memória completamente fora do controlo do Python. Se duas threads WSGI tentarem executar uma função da GDAL em simultâneo, acedem ao mesmo espaço de memória sem verificações de segurança. Uma thread corrompe os dados que a outra thread está a usar. Como isto acontece ao nível do C, o Python não consegue lançar uma exception standard. O resultado é um segmentation fault. O processo do servidor morre instantaneamente, levando consigo quaisquer requests ativos de utilizadores. Para resolver isto, tens de mudar a forma como o teu servidor WSGI lida com a concorrência. Tens de recorrer a processos em vez de threads. Os sistemas operativos isolam os processos uns dos outros, dando a cada processo o seu próprio espaço de memória dedicado. Se estiveres a fazer push de uma app geográfica de alto tráfego para produção usando Apache e mod_wsgi, tratas disto na configuração do daemon. Em vez de configurares um pequeno número de processos com uma grande pool de threads, restringes as threads. Abres o teu ficheiro de configuração do Apache e localizas a diretiva do daemon process do WSGI. Ao lado do nome da aplicação, adicionas um parâmetro a definir explicitamente as threads para exatamente uma. Depois, escalas a aplicação aumentando o número de processos para lidar com a carga esperada. A mesma lógica aplica-se se usares um servidor como o Gunicorn. Tens de lhe fazer bind para worker processes standard. Evitas qualquer worker class que introduza threading ou event loops assíncronos, porque vão inevitavelmente desencadear as mesmas colisões na GDAL. Forçar o teu servidor WSGI a um modelo multi-process e single-threaded garante que a GDAL nunca colide consigo própria. O passo mais crucial para tornar uma app GeoDjango production-ready é isolar as tuas bibliotecas de C da concorrência de threads. Isto conclui toda a nossa série sobre GeoDjango e PostGIS. A melhor forma de consolidar estes conceitos é ler a documentação oficial do Django e construir algo hands-on. Se tiveres ideias sobre que tecnologia devemos cobrir a seguir, visita devstories dot eu e sugere um tópico. Obrigado por ouvirem. Fiquem bem, pessoal.