GeoDjango and PostGIS

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 1 di 15. Hai mai provato a calcolare la distanza tra due punti di latitudine e longitudine usando una normale query SQL? Di solito finisci per scrivere un blocco di trigonometria enorme e fragile solo per capire quale bar è il più vicino. I database standard semplicemente non capiscono lo spazio fisico. Risolvere questo gap nei dati è esattamente quello di cui parliamo oggi ne Il potere dei framework web spaziali. Spesso si pensa che salvare dati geografici significhi solo aggiungere due colonne decimali a una tabella del database, una per la latitudine e una per la longitudine. Questo è un malinteso comune. Se stai costruendo un sistema di routing per il food delivery e devi trovare il ristorante più vicino a un cliente, un database standard tratta quelle coordinate come numeri floating-point arbitrari. Non sa che la Terra è una sfera. Non riesce a calcolare in modo efficiente confini, intersezioni o distanze nel mondo reale. Sei costretto a caricare migliaia di record nella memory della tua applicazione e a fare i calcoli da solo. È qui che entra in gioco un database spaziale. PostGIS è un'estensione spaziale per il database PostgreSQL. Cambia radicalmente il modo in cui i dati vengono salvati. Invece di due colonne numeriche separate, salvi un singolo object geometry o geography. Un database spaziale capisce nativamente la matematica del mondo fisico. Sa cosa sono un point, una line e un polygon. Se vuoi trovare tutti i ristoranti in un raggio di due chilometri da un utente, PostGIS usa degli index spaziali specializzati per trovare la risposta all'istante a livello di database. Ma un database intelligente è solo metà della soluzione. Devi ancora collegare quella logica spaziale alla tua web application. Questo ci porta a GeoDjango. GeoDjango è un framework geografico di altissimo livello integrato direttamente in Django. Fa da ponte tra il tuo database spaziale e la logica della tua applicazione. GeoDjango estende l'Object-Relational Mapper standard di Django in modo da poter capire le geometry di PostGIS. Interagisci con i dati geografici esattamente come interagisci con i normali model del database. Invece di scrivere query SQL spaziali raw, usi Python. Puoi filtrare i risultati del database in base alle relazioni spaziali, come verificare se il polygon della zona di consegna di un ristorante contiene un point specifico dell'indirizzo dell'utente. GeoDjango traduce il tuo codice Python nelle query PostGIS corrette. Include persino dei map widget per il pannello di amministrazione di Django, così puoi creare e modificare visivamente i dati geografici out of the box. Insieme, PostGIS e GeoDjango formano uno stack incredibilmente potente. PostGIS gestisce il lavoro matematico pesante a livello di storage, e GeoDjango fornisce un'interfaccia Python pulita per servire quei dati ai tuoi utenti. Smetti di lottare con la trigonometria complessa e inizi a creare vere feature location-aware. Ecco il punto chiave. La vera potenza di un framework spaziale non è solo disegnare linee su una web map. È spostare la complessa matematica spaziale completamente fuori dal codice della tua applicazione, dentro un database engine costruito appositamente per capire la geometry. Se trovi utili questi deep dive, puoi supportare lo show cercando DevStoriesEU su Patreon. Per oggi è tutto. Grazie per l'ascolto: vai a creare qualcosa di fantastico!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 2 di 15. Il percorso più breve tra due punti sulla Terra non è una linea retta, è una curva. Se il tuo database tratta la longitudine e la latitudine come una normale griglia X e Y, le tue query di distanza saranno completamente sbagliate. Per risolvere questo problema devi capire la differenza tra i tipi di dato Geometry e Geography di PostGIS. Di default, i database spaziali operano su un piano bidimensionale piatto. Questo è il tipo Geometry. Utilizza la matematica cartesiana standard. Se vuoi trovare la distanza tra due punti, il database in pratica traccia una linea retta e applica il teorema di Pitagora. Questo approccio è incredibilmente veloce e molto preciso per i dati locali. Se stai mappando un isolato, tracciando le pareti di un edificio o individuando il confine esatto di un piccolo parco, la curvatura terrestre è trascurabile. Una mappa piatta funziona perfettamente. Spesso gli sviluppatori pensano di poter usare il tipo Geometry per tutto. Salvano le coordinate GPS globali, che sono gradi di longitudine e latitudine, dentro una colonna Geometry piatta. Quando chiedono al database di calcolare una distanza, questo restituisce un numero senza senso in gradi, invece che in metri o miglia. Per ottenere distanze reali su grandi aree con il tipo Geometry, devi convertire continuamente i tuoi dati in proiezioni cartografiche specifiche e localizzate. Questo è esattamente il motivo per cui PostGIS fornisce il tipo Geography. Il tipo Geography modella la Terra come una sfera. Nello specifico, utilizza nativamente il sistema di riferimento spaziale WGS84. Quando salvi le coordinate in una colonna Geography, il database capisce che la superficie è curva. Quando gli chiedi una distanza, non traccia una linea piatta. Calcola la rotta del cerchio massimo. Pensa di misurare una rotta di volo da New York a Londra. Se usi il tipo Geometry su una mappa piatta standard non proiettata, il database calcola una linea retta che taglia direttamente la griglia. Se usi il tipo Geography, il database calcola la vera distanza più breve seguendo la curvatura della Terra, tracciando il cerchio massimo sull'Atlantico. Ancora meglio, il tipo Geography restituisce automaticamente questa distanza in metri. Eviti completamente la necessità di gestire da solo complesse proiezioni cartografiche. Ecco il punto fondamentale. Potresti concludere che Geography sia il tipo superiore e che debba sostituire completamente Geometry. Questo è falso. Calcolare le distanze su una sfera richiede una trigonometria pesante. Richiede molta più potenza di calcolo rispetto alla matematica su un piano piatto, rendendo le operazioni sui tipi Geography più lente. Inoltre, PostGIS supporta molte meno funzioni spaziali per Geography rispetto a Geometry. Molte operazioni geometriche avanzate semplicemente non si traducono in matematica sferica. La tua scelta dipende interamente dall'estensione fisica dei tuoi dati. Usa il tipo Geography quando la tua applicazione salva punti a livello globale e ha bisogno di distanze accurate senza l'overhead della gestione delle proiezioni. Usa il tipo Geometry quando i tuoi dati sono limitati a una specifica regione locale, o quando hai bisogno della massima performance assoluta e della suite completa di funzioni spaziali. Il tipo che scegli definisce la forma del mondo in cui vive il tuo database. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 3 di 15. Trasformare il tuo database standard in un motore spaziale richiede esattamente tre parole SQL, ma se le esegui nel contesto sbagliato, la tua applicazione Django fallirà già alla primissima migration. Oggi ci concentriamo interamente sulla configurazione del tuo ambiente spaziale. Iniziamo dal database layer. Hai già PostgreSQL in esecuzione e hai creato un database vuoto per il tuo nuovo progetto. In questa fase, quel database è completamente standard. Comprende solo testo, integer, date e tipi relazionali standard. Non ha alcuna idea di cosa sia una coordinata o un geographic boundary. Per cambiare le cose, devi abilitare PostGIS. Spesso le persone si bloccano qui, dando per scontato che installare i package di PostGIS sul server renda automaticamente ogni database spatially aware. Non è così. L'estensione spaziale deve essere creata all'interno dello specifico database che userà il tuo progetto. Devi connetterti direttamente a quel nuovo database usando un database client o la command line. Una volta connesso, esegui il comando per creare l'estensione chiamata postgis. Queste tre parole SQL trasformano all'istante l'ambiente. PostgreSQL esegue il comando, caricando centinaia di funzioni spaziali e data type specializzati nel tuo schema. Genera anche una system table fondamentale che memorizza i sistemi di riferimento spaziale, che forniscono le formule matematiche necessarie per proiettare le coordinate globali su uno schermo piatto. Con il database pronto, passi al tuo progetto Django. Fai il bootstrap di un progetto standard e crei una nuova app. Chiamiamo questa app world. Ora, apri il tuo file di settings. Sono necessarie due modifiche distinte per fare da ponte tra Django e PostGIS. Per prima cosa, individua il tuo array installed apps. Devi aggiungere il modulo chiamato django dot contrib dot gis. Questo modulo è il cuore di GeoDjango. Carica i wrapper Python per le librerie geografiche sottostanti, fornendo gli spatial field e i database lookup geografici che userai più avanti per scrivere le tue query. Aggiungi anche la tua nuova app world a questa lista, in modo che Django sappia di dover tracciare i suoi model. Ecco il punto chiave. La seconda modifica avviene nel tuo dictionary di configurazione del database. Django instrada tutto il traffico del database attraverso un engine backend. Se lasci l'engine impostato sul backend PostgreSQL di default, Django tratterà il tuo database spaziale come un database relazionale standard. Non saprà come serializzare una geographic shape o fare il parse in sicurezza di una bounding box query. Devi puntare esplicitamente l'engine al backend PostGIS di GeoDjango. Cambi il valore dell'engine in django dot contrib dot gis dot db dot backends dot postgis. Il resto del dictionary di connessione rimane identico. Fornisci ancora il nome del database, lo user, la password, l'host e la porta esattamente come faresti per un setup standard. Quando esegui le tue migration iniziali, questo nuovo backend prende il controllo. Si connette a PostgreSQL e controlla immediatamente la presenza dell'estensione PostGIS. Se ti sei dimenticato di creare l'estensione nel database, il backend intercetterà gli spatial type mancanti e lancerà un errore. Se l'estensione è presente, la connessione va a buon fine. Ora hai una spatial pipeline completa. Il vero potere di questa specifica configurazione è che, una volta collegato il backend postgis, l'enorme complessità delle query del database spaziale viene completamente nascosta dietro il familiare Object Relational Mapper di Django. Questo è tutto per questo episodio. Grazie per aver ascoltato, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 4 di 15. Prova a misurare l'impronta di un edificio usando latitudine e longitudine, e i tuoi numeri saranno completamente inutili. Questo perché latitudine e longitudine sono solo angoli rispetto al centro della Terra, non distanze fisiche. Per trasformare questi angoli in misure utilizzabili come metri o piedi, hai bisogno di un Coordinate Reference System e di un SRID. Una coordinata come 48 gradi nord e 2 gradi est è solo una coppia di numeri grezzi. Senza contesto, il tuo database non sa come mappare questi numeri nel mondo fisico. Questo contesto arriva dallo Spatial Reference System Identifier, comunemente chiamato SRID. Un SRID è semplicemente un numero intero che collega i tuoi dati grezzi delle coordinate a uno specifico modello matematico della Terra. Di default, i geometry fields di GeoDjango usano un SRID di 4326. Questo numero intero rappresenta il coordinate system WGS84. È il modello standard usato dai satelliti GPS e dalla maggior parte delle librerie di web mapping. Salva i dati usando gradi di latitudine e longitudine. WGS84 è eccellente per individuare con precisione posizioni in qualsiasi punto del globo. Tuttavia, è un sistema geografico, il che significa che modella la Terra come una forma tridimensionale. Ecco il punto chiave. Non puoi calcolare con precisione distanze o aree piane usando i gradi. La distanza fisica tra due linee di longitudine si riduce man mano che ti sposti dall'equatore verso i poli. Se provi a cercare tutti i bar entro 500 metri da un punto usando l'SRID 4326, il database deve eseguire pesanti calcoli sferici on the fly, il che è lento e spesso impreciso. Per risolvere questo problema, usi i projected coordinate systems. Un projected system appiattisce matematicamente una porzione specifica della Terra curva su una griglia bidimensionale. Una volta appiattita l'area, le coordinate passano da angoli a unità di lunghezza standard, come metri o piedi. Questo rende i calcoli delle distanze veloci e precisi usando la geometria di base. La tua scelta dell'SRID dipende interamente dallo scope della tua applicazione. Se stai creando un sistema globale di tracciamento dei voli, salvi i tuoi dati usando WGS84 e SRID 4326. I tuoi punti coprono tutto il mondo, quindi hai bisogno di un sistema globale, anche se i calcoli delle distanze sono leggermente più complessi. Se stai creando un'applicazione locale di pianificazione urbana per misurare i confini esatti delle proprietà, usare WGS84 è un errore. Invece, assegni un projected coordinate system locale al tuo spatial field. Ad esempio, potresti usare uno specifico State Plane coordinate system con il suo SRID univoco. Questi sistemi locali sono altamente specifici. Minimizzano la distorsione che si verifica quando appiattisci una sfera, ma solo per quella specifica zona geografica. Quando configuri i tuoi models in GeoDjango, definisci l'SRID direttamente sullo spatial field. Se non fai nulla, il default è 4326. Se vuoi una proiezione localizzata in metri, passi quello specifico numero intero alla field definition. GeoDjango quindi tratta tutta la geometry in quella colonna in base a quello specifico modello matematico. L'SRID giusto assicura che i calcoli delle tue distanze non si distorcano man mano che i tuoi dati si allontanano dall'equatore. Grazie per l'ascolto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 5 di 15. Vuoi aggiungere dati di geolocalizzazione alla tua applicazione, quindi potresti pensare di aggiungere due semplici campi float per latitudine e longitudine al tuo database. Ma così facendo, ti tagli completamente fuori da query spaziali avanzate, calcoli di distanza e intersezioni geometriche. Per sbloccare queste funzionalità, hai bisogno di tipi spaziali appropriati, il che ci porta alla progettazione di modelli geografici. Passare dai modelli Django standard ai modelli GeoDjango richiede solo una piccola modifica ai tuoi import. Invece di usare i database models standard di Django, importi i modelli dal modulo geographic contrib. Questo modulo personalizzato fornisce un drop-in replacement. Ti dà accesso a tutti i field type standard di Django, come character e integer, introducendo al contempo i tipi spaziali nella stessa identica definizione di classe. Prendi uno scenario in cui stai creando un modello WorldBorder per memorizzare i dati dei paesi. Definisci la classe del modello come qualsiasi altra. Assegni un campo character per il nome del paese, un campo integer per la popolazione e un campo float per la superficie totale. Per gestire la geometria effettiva della mappa, aggiungi un campo geografico direttamente accanto agli altri. Per un paese, useresti un MultiPolygonField. Mentre un PointField è perfetto per memorizzare una singola coppia di coordinate come una capitale, un MultiPolygonField può rappresentare confini nazionali complessi, incluse nazioni con più masse continentali disconnesse o isole al largo. Quando colleghi questo campo spaziale al tuo modello, stai definendo un sistema di coordinate dietro le quinte. Ogni campo geografico si basa su uno Spatial Reference System Identifier, noto come SRID. L'SRID dice al database come proiettare i numeri grezzi delle coordinate sulla forma reale della Terra. Se non imposti esplicitamente questo valore, GeoDjango imposta automaticamente l'SRID di default a 4326. Quello specifico integer si riferisce allo standard WGS84, che è esattamente lo stesso sistema di coordinate utilizzato dall'hardware GPS standard. Se i tuoi dati di origine si basano su una proiezione locale diversa, ti basta passare l'integer di destinazione al parametro SRID direttamente all'interno della definizione del campo. Ed è qui che la cosa si fa interessante. Gli sviluppatori che hanno familiarità con l'ORM di Django sanno che per rendere una colonna veloce da interrogare, devi passare esplicitamente un flag di database index alla definizione del campo. Poiché le query spaziali sono intrinsecamente pesanti, potresti pensare di dover configurare manualmente degli index specializzati per le tue colonne geometriche. Non è così. I campi geografici in GeoDjango funzionano in modo diverso. Includono un parametro specifico per lo spatial indexing, e il suo valore di default è true. Quando esegui le tue migration, GeoDjango dice automaticamente al database sottostante di creare uno spatial index specializzato. Ottieni query di bounding box ad alte prestazioni e lookup di intersezioni geografiche out of the box, con zero configurazioni extra. Il vero punto di forza di progettare i modelli in questo modo è che demistifica completamente i dati spaziali. Un poligono enorme e complesso che rappresenta un continente diventa semplicemente un'altra property sul tuo oggetto Python, pronta per essere salvata e interrogata insieme a un semplice conteggio della popolazione. Questo è tutto per oggi. Grazie per l'ascolto: vai a costruire qualcosa di fantastico.

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 6 di 15. Ti viene consegnato un file spaziale di grandi dimensioni — un ESRI Shapefile o un GeoJSON — e devi sapere quali attributi contiene. Il tuo primo istinto potrebbe essere quello di installare un pesante programma GIS desktop solo per dare un'occhiata. Non devi farlo. GeoDjango può leggere questi file nativamente direttamente nella shell Python utilizzando l'API di GDAL e OGR. Se i sistemi informativi geografici sono una cassetta degli attrezzi, la Geospatial Data Abstraction Library è il traduttore universale. Tecnicamente, GDAL gestisce i dati raster come le immagini satellitari, mentre il suo partner OGR gestisce i dati vettoriali come punti, linee e poligoni. GeoDjango include un wrapper Pythonic attorno alla libreria OGR, offrendoti un modo diretto per ispezionare quasi ogni formato di file vettoriale sul pianeta. Mettiamo che tu abbia scaricato uno shapefile contenente i confini di tutti i paesi del mondo. Prima di scrivere uno script per acquisire questi dati, devi sapere esattamente come sono strutturati. Inizi importando l'oggetto DataSource dal modulo GDAL di GeoDjango. Crei un nuovo data source passandogli il file path del tuo shapefile. Questo oggetto ora rappresenta l'intero dataset spaziale che hai scaricato. Un data source organizza le sue informazioni spaziali in layer. Puoi chiedere al data source il conteggio dei suoi layer. Un ESRI Shapefile tradizionalmente contiene un solo layer, ma formati come i GeoPackage potrebbero contenerne decine. Recuperi quel primo layer usando il suo index, esattamente come quando estrai un item da una list Python standard. Ecco il punto chiave. L'oggetto layer è dove avviene l'introspezione vera e propria. Funge da contenitore per i singoli record spaziali, che l'API chiama feature. Puoi chiedere al layer di restituire il suo conteggio totale di feature. Per il nostro file dei confini mondiali, il conteggio dovrebbe corrispondere all'incirca al numero di paesi sulla Terra. Puoi anche chiedere al layer il suo geometry type. Questo conferma se i dati sono costituiti da punti, linee o poligoni. Per i confini dei paesi, il tipo in genere risponderà come MultiPolygon. Successivamente, devi sapere quali metadati sono associati a quelle forme. Puoi chiedere al layer i suoi field. Questo restituisce una list di string che rappresentano i nomi delle colonne degli attributi. Potresti vedere nomi che corrispondono a un codice paese interno, un nome comune e un conteggio della popolazione. Puoi persino scendere di un livello. Accedendo a una singola feature dal layer tramite il suo index, puoi ispezionare un singolo paese. Puoi chiedere a quella specifica feature il valore del suo field del nome comune. Puoi anche accedere allo specifico oggetto geometry di quella feature e chiedergli di mandare in output le sue coordinate come well-known text o GeoJSON. Ora hai mappato esattamente quali forme contiene il file, i nomi dei suoi attributi e la struttura dei suoi record. Hai fatto tutto questo puramente tramite Python, senza scrivere uno script di importazione per il database o affidarti a software di visualizzazione esterni. Il wrapper GDAL trasforma la tua shell Python standard in una lente esplorativa per i dati spaziali, consentendoti di validare file esterni prima che un singolo record tocchi il tuo database. Questo è tutto per questo episodio. Grazie per l'ascolto e continua a costruire!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 7 di 15. Importare manualmente migliaia di poligoni geografici e i relativi metadati potrebbe richiedere giorni. I tuoi file sorgente hanno nomi di colonna criptici e tipi non corrispondenti, ma il tuo database richiede una struttura rigorosa. La soluzione è l'utility LayerMapping di GeoDjango, che gestisce l'intero processo di ingestion con esattamente un dictionary. Quando lavori con dati spaziali, ricevi spesso file vettoriali come gli Shapefile di ESRI. Questi file contengono sia le forme geometriche delle posizioni, sia i dati degli attributi associati a quelle forme. Tuttavia, i file esterni raramente corrispondono allo schema del tuo database. Uno Shapefile potrebbe avere una colonna per la popolazione abbreviata in POP2005 e un codice paese indicato come ISO2. Il tuo perfetto modello Django, chiamiamolo WorldBorder, ha campi con nomi chiari e strettamente tipizzati per quegli stessi attributi. Potresti essere tentato di usare importazioni SQL manuali o tool di database come pgAdmin per inserire questi dati in PostGIS. LayerMapping è un approccio completamente diverso. È un'utility programmatica basata su script Python. Vive direttamente all'interno del tuo progetto Django, collegando i file spaziali esterni direttamente al tuo Object Relational Mapper. Ecco il punto chiave. Il cuore di LayerMapping è un semplice dictionary Python. Le chiavi di questo dictionary sono i nomi dei campi del tuo modello Django pulito. I valori sono i nomi degli attributi nel tuo file sorgente, sotto forma di raw string. Ad esempio, il tuo dictionary mappa il nome del campo del modello Django all'attributo NAME dello Shapefile. Mappa il campo population del tuo modello a POP2005, e il campo iso code a ISO2. Mappi anche il campo geometry sul tuo modello al tipo di geometria dello Shapefile, che di solito è rappresentato da una string come MULTIPOLYGON. Per automatizzare tutto questo, scrivi un breve file Python, in genere chiamato load script. All'interno di questo script, importi il tuo modello WorldBorder e il tool LayerMapping. Definisci il tuo dictionary di mapping. Poi, crei una nuova instance di LayerMapping. Passi a questa instance tre informazioni obbligatorie. Primo, il tuo modello Django. Secondo, il file path del tuo Shapefile sorgente. Terzo, il dictionary di mapping che hai appena creato. Puoi anche fornire degli argument opzionali per controllare il comportamento di ingestion. Se i tuoi dati sorgente sono già nell'esatto sistema di riferimento spaziale che il tuo database si aspetta, puoi dire all'utility di non eseguire trasformazioni di coordinate. Questo salta calcoli inutili e velocizza l'import. Infine, chiami il method save sulla tua instance di LayerMapping. Quando esegui questo script, l'utility prende completamente il controllo. Apre lo Shapefile, itera attraverso ogni singola feature geografica, e usa il tuo dictionary per allineare gli attributi disordinati del file con i campi rigorosi del tuo modello. Traduce automaticamente la raw geometry in un formato che PostGIS capisce, e salva i record nel tuo database. Puoi istruire il method save per sollevare un'exception al primo errore che incontra, oppure puoi lasciarlo girare e semplicemente loggare qualsiasi feature problematica sul tuo terminale. La cosa più importante da ricordare è che LayerMapping disaccoppia completamente la struttura rigida dei file spaziali esterni dal design pulito del tuo database, permettendoti di fare l'ingestion di enormi dataset con solo poche righe di Python. Prima di concludere, se ti piace lo show e vuoi aiutarci a portarlo avanti, puoi supportarci cercando DevStoriesEU su Patreon. Questo è tutto per questo episodio. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 8 di 15. Potresti pensare che ogni volta che devi unire due poligoni o trovare un'intersezione spaziale, tu debba scrivere una query e aspettare che il database restituisca una risposta. La realtà è che puoi fare complessi calcoli matematici spaziali direttamente nella tua shell Python, senza mai toccare una connessione al database. Ed è esattamente quello di cui parliamo oggi: l'API GEOS e la geometria pythonica. Un falso mito su GeoDjango è che PostGIS si occupi di tutto il lavoro pesante spaziale. Anche se PostGIS è incredibilmente potente, l'API GEOS ti permette di eseguire operazioni geometriche interamente in memoria locale. GEOS sta per Geometry Engine Open Source. È una libreria C++ altamente ottimizzata, ma GeoDjango ti offre un potente wrapper chiamato oggetto GEOSGeometry. Questo oggetto ti permette di creare, manipolare e analizzare geometrie puramente in Python. Ed è qui che la cosa si fa interessante. Un oggetto GEOSGeometry non sembra un wrapper goffo attorno a una libreria C. Si comporta esattamente come un container nativo Python. Se hai una LineString con dieci punti, puoi eseguirci sopra la funzione standard length di Python per vedere che ha dieci coordinate. Puoi iterare su un Polygon con uno standard for-loop per estrarre i suoi singoli anelli, oppure usare un indice per prendere un punto specifico da una geometria MultiPoint. Si comportano proprio come le familiari list o tuple di coordinate. La vera potenza si sblocca quando applichi operazioni topologiche. Mettiamo che tu stia costruendo un'applicazione di logistica e che tu abbia due zone di consegna sovrapposte definite come GEOS Polygons. Devi trovare l'area esatta in cui queste due zone si sovrappongono. Non hai bisogno di salvare queste zone in un model ed eseguire una query sul database. Invece, puoi generare la sovrapposizione all'istante in memoria. Per prima cosa, istanzi due oggetti GEOSGeometry che rappresentano le tue zone di consegna. Poi, puoi semplicemente chiamare il metodo intersection sul primo poligono, passando il secondo poligono come argomento. Dato che l'API è profondamente pythonica, puoi anche solo usare l'operatore bitwise AND. Digiti letteralmente poligono uno, una e commerciale, e poligono due. Questo restituisce un oggetto GEOSGeometry nuovo di zecca che rappresenta l'esatta forma sovrapposta. Hai accesso a una suite completa di queste operazioni spaziali. Se devi trovare l'area coperta dalla prima zona di consegna ma strettamente fuori dalla seconda, usi il metodo difference, o il normale operatore meno di Python. Se vuoi unirle in un'unica zona enorme, usi il metodo union, o l'operatore bitwise OR pipe. Puoi persino generare nuove forme dal nulla. Chiamare il metodo buffer su una geometria point con un argomento width calcola e restituisce all'istante un poligono che rappresenta un cerchio perfetto disegnato attorno a quel punto. Dato che tutto si basa sul motore C++ sottostante, questi calcoli avvengono in modo estremamente veloce. Il punto chiave qui è che l'API GEOS ti dà un motore spaziale in-memory indipendente, permettendoti di validare le geometrie, calcolare i buffer e trovare le intersezioni prima ancora che un singolo byte di dati raggiunga il tuo database. Questo è tutto per questo episodio. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 9 di 15. Dimentica di scrivere enormi confronti di coordinate. Hai la posizione di un utente e una zona di consegna, e devi sapere se si sovrappongono. Farlo matematicamente significa controllare centinaia di lati di poligoni nella logica della tua applicazione. Invece, GeoDjango riduce tutto questo a un'operazione di database. Oggi impareremo a padroneggiare gli spatial lookup. Se hai già usato Django, conosci la sintassi con il doppio underscore per filtrare i queryset. Aggiungi qualcosa come doppio underscore exact o doppio underscore in al nome di un campo. GeoDjango estende esattamente questa stessa sintassi per eseguire complesse relazioni topologiche in PostGIS. Le relazioni topologiche sono semplicemente regole su come le geometrie condividono lo spazio. Si toccano? Si sovrappongono? Una è completamente all'interno dell'altra? GeoDjango ti offre dei lookup dedicati per fare queste domande direttamente nelle tue query dell'ORM. Lo spatial lookup più comune e flessibile è intersects. Se filtri un campo geometry con doppio underscore intersects, il database restituisce i record in cui le due geometrie condividono una qualsiasi porzione di spazio. Possono incrociarsi, toccarsi su un confine, o una può racchiudere completamente l'altra. Finché c'è dello spazio condiviso, intersects restituisce true. Spesso hai bisogno di più precisione rispetto a una semplice intersezione. Ti servono confini rigorosi. È qui che entrano in gioco contains e within. I developer li confondono continuamente. Ecco il punto chiave. La differenza è puramente direzionale. Se la geometria A contiene la geometria B, allora la geometria B è all'interno della geometria A. Pensa a una scatola e a una biglia. La scatola contiene la biglia. La biglia è all'interno della scatola. Scegli il lookup in base a quale geometria si trova nella colonna del tuo database e a quale geometria stai passando come argomento del filter. Considera uno scenario concreto. Hai una tabella del database con delle case, e ogni casa ha una point geometry che rappresenta la sua posizione. La città ha appena rilasciato un nuovo polygon che definisce una zona a rischio alluvione. Devi trovare tutte le case che si trovano perfettamente all'interno di quell'area di rischio. Non fai una query sulla zona alluvionale per vedere cosa contiene. Fai una query sulle case. Chiami filter sul model della casa, fai riferimento al campo della point geometry, aggiungi doppio underscore within, e passi il polygon della zona alluvionale come valore. Quando esegui questa query, Django traduce il tuo lookup con doppio underscore in una chiamata a una funzione nativa di PostGIS, nello specifico ST_Within. Il database engine valuta le geometrie usando i suoi spatial index ottimizzati. Controlla se ogni singola coordinata del point della casa si trova all'interno del polygon della zona alluvionale. Se la casa si trova esattamente sul bordo del polygon, non viene considerata within. Il contenimento rigoroso significa che l'interno della prima geometria deve trovarsi completamente all'interno della seconda geometria. Se inverti lo scenario, diciamo che stai facendo una query su una tabella di database di quartieri per trovare quello che circonda una specifica posizione dell'utente, usi doppio underscore contains. Filtri il campo del polygon del quartiere, aggiungi doppio underscore contains, e passi il point dell'utente. La logica dietro le quinte è identica, ma l'ordine degli argomenti spaziali passati a PostGIS viene invertito. Capire questa logica direzionale previene silent failure e queryset vuoti. Mappando le operazioni di PostGIS direttamente sui keyword argument di Django, puoi filtrare in modo efficiente enormi dataset spaziali senza scrivere raw SQL. La geometria su cui stai filtrando detta sempre la direzione del tuo spatial lookup. Grazie per averci seguito. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 10 di 15. Le query di raggio sono il pane quotidiano delle applicazioni geolocalizzate. Se le scrivi male, il tuo database calcola la distanza esatta per ogni singola riga della tua tabella, forzando un enorme full scan. Se le scrivi bene, ci vogliono pochi millisecondi. Le query di distanza ad alte prestazioni fanno la differenza tra un'app reattiva e una che crasha sotto carico. Un errore comune che fanno gli sviluppatori è pensare alle query spaziali come se fossero matematica di base. L'approccio ingenuo è calcolare la distanza precisa dal tuo punto di partenza a ogni altro punto nel database, per poi filtrare tutto ciò che supera il tuo raggio massimo. Non dovresti mai farlo. Calcolare le distanze reali su una sfera è un'operazione computazionalmente pesante. Se la tua query filtra calcolando prima la distanza, il database non può usare i suoi indici spaziali. È costretto a controllare ogni singola riga. Per mantenere le query veloci, devi affidarti a lookup basati sugli indici. Prima di guardare i lookup del database, ti serve un modo per esprimere la distanza in modo chiaro nel tuo codice Python. GeoDjango fornisce l'oggetto Distance, comunemente importato semplicemente come la lettera D maiuscola. Lo inizializzi con un'unità e un valore. Per esempio, passando l'argomento m i uguale a cinque a questo oggetto, crei una misurazione di esattamente cinque miglia. Puoi usare chilometri, metri o persino gradi. Questo normalizza la misurazione in Python prima ancora che la query arrivi al database. Immagina uno scenario in cui stai implementando una feature che trova tutte le caffetterie entro un raggio di cinque miglia dal ping GPS attuale di un utente. Hai il punto di posizione dell'utente e vuoi fare una query sul tuo model delle caffetterie. Potresti usare il lookup distance less-than-or-equal. Scrivi un filtro nella query in cui il tuo campo location della caffetteria è seguito da un doppio underscore, la parola distance, un underscore e le lettere l t e. Gli passi una tupla che contiene il punto dell'utente e il tuo oggetto Distance impostato a cinque miglia. Questo funziona. Si traduce in una funzione del database che controlla se la distanza è minore o uguale a cinque miglia. Ma, a seconda del tuo backend spaziale e di come sono impostate le tue colonne, questo lookup potrebbe comunque fare più lavoro matematico dello stretto necessario, calcolando le distanze esatte prima di fare il confronto finale. Ecco il punto chiave. Raramente hai bisogno di conoscere la distanza esatta per filtrare un raggio. Ti basta sapere se l'oggetto si trova all'interno del cerchio. È qui che il lookup dwithin diventa essenziale. Invece di distance less-than-or-equal, aggiungi un doppio underscore e la parola dwithin al tuo campo location. Gli passi esattamente lo stesso punto dell'utente e l'oggetto Distance di cinque miglia. Dietro le quinte, questo viene indirizzato direttamente alla funzione PostGIS ST DWithin. Questa funzione è altamente ottimizzata. Fa prima un rapido controllo del bounding box, che sfrutta perfettamente i tuoi indici spaziali. Disegna un quadrato approssimativo attorno al tuo raggio di cinque miglia e scarta immediatamente tutti i punti fuori da quel quadrato, senza fare complessi calcoli sferici. Esegue calcoli precisi e costosi solo per i pochi punti che cadono vicino al bordo del cerchio all'interno di quel quadrato. Se la tua tabella del database usa colonne geography invece delle classiche colonne geometry, PostGIS gestisce automaticamente la curvatura terrestre mantenendo comunque l'uso degli indici fulmineo. L'abitudine più preziosa nella programmazione spaziale è rendersi conto che controllare se un punto si trova all'interno di una forma è sempre più economico che tirare fuori un metro a nastro per calcolare la distanza esatta tra di loro. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 11 di 15. Hai un database pieno di poligoni enormi e complessi, e il tuo frontend deve semplicemente visualizzare un pin al centro di ciascuno di essi. Se porti questi poligoni raw in Python per calcolare il centro, stai trascinando megabyte di dati di coordinate inutili attraverso la rete. La soluzione è delegare questi calcoli al database usando le Geographic Database Functions. Ci sono due modi per ottenere informazioni spaziali come l'area o un punto centrale in GeoDjango. Il primo è fare una query sul record del database, tirare l'intera geometry in un oggetto GEOS di Python e accedere a una proprietà come dot area. Non farlo a meno che tu non abbia effettivamente bisogno dell'intera geometry in Python. Recuperare il confine di un parco nazionale potrebbe significare caricare decine di migliaia di vertici in memoria solo per calcolare un singolo numero. Il secondo modo, molto più efficiente, è dire a PostGIS di calcolare la risposta e rimandare indietro solo il risultato finale. È qui che le Geographic Database Functions, combinate con il metodo annotate dell'ORM di Django, diventano essenziali. Vediamo uno scenario pratico. Stai creando un'API che elenca i parchi nazionali. Per la list view, l'applicazione client ha bisogno solo del nome del parco, della sua area totale e di una singola coordinata centrale per posizionare un pin sulla mappa. Non ha bisogno del complesso poligono di confine. Nel tuo queryset di Django, usi il metodo annotate. Gli dici di creare un nuovo attributo, magari chiamato park area, e di impostarlo uguale alla funzione Area che agisce sulla tua colonna geometry. Accanto a questo, crei un altro attributo chiamato center point, impostato uguale alla funzione Centroid su quella stessa colonna geometry. Infine, limiti l'output della query solo al nome e alle tue due nuove annotations. Quando questa query viene eseguita, PostGIS legge i dati raw della geometry sul disco. Esegue routine interne altamente ottimizzate per calcolare l'area spaziale e trovare il punto centrale matematico. Poi restituisce esattamente tre cose attraverso la rete alla tua applicazione Django: una stringa di testo per il nome, un numero per l'area e una single point geometry per il centro. Eviti completamente i costi di banda e di memoria per il trasferimento del grande poligono. Questa strategia si applica a molte operazioni spaziali. Puoi usare la funzione Transform all'interno di un'annotation per convertire le coordinate dalla proiezione di storage del tuo database direttamente nella proiezione di cui ha bisogno la tua web map, come Web Mercator. Il database gestisce i calcoli prima ancora che Python veda i dati. Puoi anche usare la funzione AsGeoJSON. Questo dice a PostGIS di formattare i dati spaziali in una stringa di testo JSON standard direttamente nel database. Quando Django lo riceve, è solo testo pronto per essere passato direttamente al tuo frontend, evitando completamente l'overhead di serializzazione di Python. Puoi anche applicare funzioni di aggregazione a interi queryset. La funzione Extent guarda un gruppo di geometry e restituisce un singolo bounding box che le copre tutte. Se un utente cerca tutti i parchi in una regione specifica, restituire l'Extent ti dà le coordinate esatte necessarie per fare lo zoom automatico della mappa frontend per adattarla perfettamente a tutti i risultati. Ecco il punto chiave. Il tuo database spaziale è un motore di calcolo altamente specializzato, non solo un contenitore di storage. Mantieni i tuoi calcoli spaziali pesanti all'interno di PostGIS, e sposta attraverso la rete verso Python solo le risposte calcolate. Per questo episodio è tutto. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 12 di 15. Le forme vettoriali sono ottime quando vuoi tracciare una linea netta attorno al confine di una città o individuare la posizione di un utente. Ma cosa succede quando devi mappare qualcosa che non ha confini ben definiti, come le variazioni di temperatura in un continente o l'altitudine di un'intera catena montuosa? Non puoi disegnare un poligono per ogni singolo grado di temperatura. È qui che entrano in gioco i Raster Data in PostGIS. Se sei abituato a lavorare con punti, linee e poligoni, i dati raster richiedono un cambio di prospettiva. I dati raster non sono fatti di forme discrete. Sono una griglia continua di pixel, esattamente come una fotografia digitale. Ma invece dei valori di colore rosso, verde e blu, ogni pixel contiene uno specifico dato numerico. Quel dato potrebbe essere la quantità di pioggia, il tipo di suolo o l'altitudine. L'intera griglia è legata matematicamente al mondo reale tramite la georeferenziazione. Questo significa che il database sa esattamente dove si trova ogni singolo pixel sulla mappa. In GeoDjango, la gestione di questi dati coinvolge principalmente due componenti: il RasterField e l'oggetto GDALRaster. RasterField è il tipo di colonna del database. Lo aggiungi al tuo modello Django proprio come faresti con un campo geometrico. Questo dice a PostGIS di allocare internamente lo spazio per i dati della griglia. Ma non interagisci direttamente con i byte grezzi del database. Quando estrai un raster dal database, o prima di inserirne uno, usi GDALRaster. È un wrapper Python per le librerie geospaziali sottostanti. Ti permette di ispezionare le proprietà del raster, come la sua scala, il suo sistema di riferimento delle coordinate e i valori effettivi all'interno delle sue bande. Una banda è semplicemente un singolo livello di dati nella griglia. Un'immagine standard ha tre bande per il colore, ma una mappa di elevazione in genere ha solo una banda che rappresenta l'altezza. Considera uno scenario concreto. Stai sviluppando un'applicazione per escursionisti e hai un Digital Elevation Model di una catena montuosa. Questo modello di elevazione di solito viene fornito come file GeoTIFF. Per prima cosa, definisci un modello Django per la tua catena montuosa e gli assegni un RasterField. Poi, nel tuo codice Python, istanzi un GDALRaster passandogli il percorso del file del tuo GeoTIFF. Django carica il file in memoria come oggetto GDALRaster. Assegni quell'oggetto al RasterField sul tuo modello della montagna e chiami save. PostGIS prende quella griglia e la memorizza. Ora, quando un escursionista carica il suo percorso GPS, puoi fare una query sul database per scoprire esattamente in quale pixel ricadono le sue coordinate. Estrai il valore di elevazione memorizzato in quello specifico pixel. Quando rileggi quel campo dal database, Django ti restituisce di nuovo un oggetto GDALRaster. Puoi chiedere a questo oggetto la sua larghezza, la sua altezza o la sua estensione spaziale. Puoi accedere direttamente agli array dei dati grezzi dei pixel in Python per eseguire dei calcoli prima di inviare i dati al frontend della tua applicazione. Questo è il punto chiave. Usi i vettori per le cose che esistono in un luogo specifico, e usi i raster per le cose che esistono ovunque in un'area. Combinandoli entrambi in PostGIS, la tua applicazione può mettere in relazione oggetti discreti, come un sentiero escursionistico, con ambienti continui, come l'altitudine effettiva del terreno sotto i piedi. Se vuoi dare una mano a sostenere lo show, puoi cercare DevStoriesEU su Patreon: il tuo supporto significa molto. Per questo episodio è tutto. Grazie per l'ascolto, e continua a sviluppare!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 13 di 15. Cosa succede se hai bisogno di sapere dove si trova un utente per fornirgli contenuti locali, ma non ti ha concesso i permessi GPS? Il suo indirizzo IP in entrata contiene la risposta. Questa è la Geolocation con GeoIP2. Per essere chiari fin da subito, la Geolocation IP non è un lookup di coordinate preciso come un'API di Geolocation del browser. È un'approssimazione. Quando fai un lookup di un indirizzo IP, interroghi un dataset statico che mappa i blocchi IP assegnati alle aree geografiche. Ottieni quasi sempre il paese corretto e spesso anche la città giusta, ma non troverai l'indirizzo stradale effettivo dell'utente. Considera uno scenario in cui un visitatore arriva sul tuo sito e-commerce. Vuoi fare un redirect automatico allo storefront localizzato del suo paese o centrare di default una mappa sulla sua regione puramente in base al suo indirizzo IPv4 o IPv6 in entrata. GeoDjango fornisce l'oggetto GeoIP2 specificamente per gestire questo lookup offline. Prima di poter scrivere qualsiasi logica, devi avere gli elementi corretti al loro posto. Innanzitutto, installi la libreria Python geoip2 nel tuo environment. In secondo luogo, ti servono i dati effettivi. GeoIP2 si basa sui dataset MaxMind, in genere i database gratuiti GeoLite2 City o Country. Scarichi questi file, che hanno un'estensione mmdb, e li posizioni sul tuo server. Infine, nei tuoi settings di Django, definisci una variabile chiamata GEOIP_PATH e la punti alla directory contenente quei file. Django si aspetta di trovare file con nomi specifici come GeoLite2-City punto mmdb in quella cartella. Con il setup completato, usare il tool richiede solo pochi passaggi. Importi l'oggetto GeoIP2 dal modulo django contrib gis geoip2 e lo istanzi. Estrai la string dell'indirizzo IP in entrata dai tuoi request headers e la passi a uno dei metodi di lookup. Se ti serve solo una logica di routing generale, chiami il metodo country. Passi l'indirizzo IP e questo restituisce un dictionary contenente il country code e il nome del paese. Se hai bisogno di maggiore granularità per centrare una mappa, chiami invece il metodo city. Questo restituisce un dictionary più ricco contenente il nome della città, la regione e i valori approssimativi di longitudine e latitudine. Il metodo city include anche i dati del paese, quindi ti basta fare una sola chiamata. Se vuoi semplicemente le coordinate da passare a un'altra funzione, ci sono metodi dedicati come coords che restituiscono una tuple di base di longitudine e latitudine. Devi anche gestire i fallimenti in modo pulito. Se passi un indirizzo IP non valido, o un indirizzo che semplicemente non è presente nel database MaxMind, GeoIP2 non restituisce un dictionary vuoto. Solleva una GeoIP2Exception. Devi wrappare le tue chiamate di lookup in un blocco try e fornire una location di fallback di default per il tuo storefront quando il lookup fallisce. Ecco il punto chiave. Il codice in sé è essenzialmente solo un file reader ottimizzato. L'accuratezza della tua Geolocation dipende interamente dalla freschezza del database che si trova nella tua directory GEOIP_PATH. Le allocazioni IP cambiano costantemente. Se costruisci un sistema di routing basato su GeoIP2, devi automatizzare il download regolare dei nuovi file del database, altrimenti i tuoi redirect localizzati diventeranno lentamente e silenziosamente errati. Questo è tutto per questo episodio. Alla prossima!

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 14 di 15. Il testing delle applicazioni spaziali ha una particolarità: il tuo database di test automatizzato deve installare complesse estensioni spaziali a livello C prima ancora che parta il primissimo test. Se la tua pipeline automatizzata va in crash immediatamente con errori di permessi, probabilmente il motivo è questo. Oggi parliamo del testing delle applicazioni spaziali. Il primo requisito è strettamente di configurazione. Quando lanci i test, Django crea un database di test parallelo per tenere al sicuro i tuoi dati in produzione. Per GeoDjango, questo database di test deve essere spaziale. Questo significa che le impostazioni del tuo database devono usare esplicitamente un motore spaziale, come il backend PostGIS fornito da GeoDjango. Non puoi usare il backend Postgres standard e aggiungere i campi spaziali dopo. Il backend spaziale è quello che dice al test runner di Django di cercare e inizializzare le feature spaziali richieste. Ecco il punto chiave. Il test runner standard di Django crea un database pulito, esegue le tue migration e fa partire il testing. Ma per un'applicazione GeoDjango, creare un nuovo database non basta. Il database deve anche caricare l'estensione PostGIS. Non si tratta di una tabella SQL standard. È un'estensione a livello di sistema. Di default, PostgreSQL limita chi può creare estensioni per motivi di sicurezza. In genere, richiede un utente del database con privilegi da superuser. È proprio qui che le pipeline di continuous integration spesso falliscono. Tiri su un container Postgres, passi un utente del database standard e dici a Django di lanciare i test. Django si connette, tenta di fare la build del database di test, prova a lanciare il comando per creare l'estensione PostGIS e si scontra con un errore di permission denied. Per risolvere questo problema in una pipeline automatizzata, l'utente del database che esegue i test deve avere i privilegi necessari. L'approccio più semplice in un ambiente isolato e usa e getta è quello di concedere temporaneamente all'utente di test i ruoli da superuser. Se le tue policy di sicurezza vietano l'accesso da superuser anche in un container temporaneo, devi configurare PostgreSQL in modo che lo specifico utente di test sia un trusted owner del database di test e sia esplicitamente autorizzato a creare l'estensione PostGIS. Una volta che il database ha finito la build, GeoDjango ha bisogno di sapere con cosa sta lavorando. Diverse versioni di PostGIS supportano diverse funzioni spaziali. Durante le normali operazioni, GeoDjango fa una query al database per determinare la versione di PostGIS installata. Tuttavia, in un ambiente di test, puoi bypassare questa query definendo un setting specifico chiamato PostGIS Version. Lo fornisci come una tupla di tre numeri, che rappresentano le versioni major, minor e patch. Impostarlo esplicitamente può velocizzare l'inizializzazione dei test e fa da fail-safe se la connessione al database fa fatica durante il controllo iniziale della versione. Lanciare test spaziali non significa scrivere assertion diverse. È principalmente una sfida di infrastruttura. La cosa più importante da ricordare è che se il tuo utente del database di test non può creare estensioni al volo, i tuoi test non partiranno nemmeno. Sistema i privilegi del tuo utente di test per fare il bootstrap di PostGIS, e il resto della tua pipeline si comporterà esattamente come una test suite standard di Django. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. GeoDjango e PostGIS, episodio 15 di 15. La tua app geospaziale funziona perfettamente sul tuo laptop. Fai il push su un server di produzione, il traffico ha un picco, e all'improvviso l'applicazione crasha in modo silenzioso. Nessun traceback standard di Python, solo processi morti. Il problema è un conflitto di thread nel profondo di una libreria C. Fare il deploy di applicazioni GeoDjango richiede di evitare esattamente questa trappola. Il deploy di un'app web geospaziale è quasi identico al deploy di un progetto Django standard. Il routing, le connessioni al database e l'architettura del server seguono esattamente le stesse regole. Ma GeoDjango si porta dietro una variabile nascosta. Quella variabile è la Geospatial Data Abstraction Library, comunemente nota come GDAL. GDAL è una libreria C enorme e altamente ottimizzata che fa il lavoro pesante per i formati dei dati geografici e le trasformazioni di coordinate. Ecco il punto chiave. GDAL non è thread-safe. Questo spiega perché il tuo codice funziona in locale ma crasha sul server. Il server di sviluppo locale di Django gestisce le richieste in modo sequenziale. Raramente innesca un accesso concorrente alla libreria C. I server WSGI in produzione sono costruiti in modo diverso. Per gestire in modo efficiente un traffico elevato, server come Apache con mod_wsgi in genere avviano più thread all'interno di un singolo processo. Python di solito si affida al Global Interpreter Lock per impedire ai thread di collidere. Tuttavia, le librerie C gestiscono la propria memoria in modo completamente al di fuori del controllo di Python. Se due thread WSGI tentano di eseguire simultaneamente una funzione GDAL, accedono allo stesso spazio di memoria senza controlli di sicurezza. Un thread corrompe i dati che l'altro thread sta usando. Dato che questo succede a livello C, Python non può lanciare un'eccezione standard. Il risultato è un segmentation fault. Il processo del server muore all'istante, portando giù con sé qualsiasi richiesta utente attiva. Per risolvere questo problema, devi cambiare il modo in cui il tuo server WSGI gestisce la concorrenza. Devi affidarti ai processi invece che ai thread. I sistemi operativi isolano i processi l'uno dall'altro, dando a ciascun processo il proprio spazio di memoria dedicato. Se stai facendo il push in produzione di un'app geografica ad alto traffico usando Apache e mod_wsgi, gestisci questa cosa nella configurazione del daemon. Invece di configurare un piccolo numero di processi con un grande pool di thread, limiti i thread. Apri il tuo file di configurazione di Apache e individui la direttiva WSGI daemon process. Di fianco al nome dell'applicazione, aggiungi un parametro che imposta esplicitamente i thread esattamente a uno. A quel punto scali l'applicazione aumentando il numero di processi per gestire il carico previsto. La stessa logica si applica se usi un server come Gunicorn. Devi fare il bind a processi worker standard. Eviti qualsiasi worker class che introduca threading o event loop asincroni, perché innescheranno inevitabilmente le stesse collisioni con GDAL. Forzare il tuo server WSGI in un modello multi-processo e single-thread garantisce che GDAL non entri mai in collisione con se stesso. Il singolo passo più cruciale per rendere un'app GeoDjango production-ready è isolare le tue librerie C dalla concorrenza dei thread. Questo conclude la nostra intera serie su GeoDjango e PostGIS. Il modo migliore per consolidare questi concetti è leggersi la documentazione ufficiale di Django e costruire qualcosa hands-on. Se hai idee su quale tecnologia dovremmo trattare in futuro, visita devstories dot eu e suggerisci un argomento. Grazie per l'ascolto. Statemi bene, tutti.