Ce document présente les détails de l’API de modèle de GeoDjango. Tout au long de cette section, nous allons utiliser le modèle géographique suivant d’un code ZIP et d’un modèle d’élévation numérique en tant qu’exemples :
\nfrom django.contrib.gis.db import models\n\nclass Zipcode(models.Model):\n code = models.CharField(max_length=5)\n poly = models.PolygonField()\n\nclass Elevation(models.Model):\n name = models.CharField(max_length=100)\n rast = models.RasterField()\nLes champs spatiaux consistent en une série de types de champs géométriques et en un type de champ matriciel. Chaque type de champ géométrique correspond à la spécification OpenGIS Simple Features [1]. Il n’existe pas de standard équivalent pour les données matricielles.
\nGeometryFieldLien vers cette rubrique#PointFieldLien vers cette rubrique#LineStringFieldLien vers cette rubrique#PolygonFieldLien vers cette rubrique#MultiPointFieldLien vers cette rubrique#MultiLineStringFieldLien vers cette rubrique#MultiPolygonFieldLien vers cette rubrique#GeometryCollectionFieldLien vers cette rubrique#RasterFieldLien vers cette rubrique#RasterField n’est actuellement implémenté que pour le moteur PostGIS.
En plus des Options des champs disponibles habituellement pour les champs de modèles Django, les champs spatiaux possèdent les options supplémentaires suivantes. Toutes sont facultatives.
\nsridLien vers cette rubrique#Définit le SRID [2] (Spatial Reference System Identity) du champ géométrique à la valeur indiquée. La valeur par défaut est 4326 (aussi connue sous le nom WGS84, les unités étant en degrés de longitude et de latitude).
\nLe choix d’un SRID approprié pour un modèle est une décision importante que le développeur doit considérer attentivement. Le SRID est un nombre entier correspondant au système de projection qui sera utilisé pour interpréter les données de la base de données spatiale. [3] Les systèmes de projection donne le contexte des coordonnées qui définissent un emplacement. Même si les détails de la géodesie dépassent le périmètre de cette documentation, le problème général est que la Terre est sphérique et que les représentations de la Terre (par ex. les cartes papier, les cartes Web) ne le sont pas.
\nLa plupart des gens connaissent l’utilisation de la latitude et de la longitude pour faire référence à un emplacement sur la surface de la Terre. Cependant, la latitude et la longitude sont des angles, pas des distances. En d’autres termes, alors que le chemin le plus court entre deux points sur une surface plane est une ligne droite, le chemin le plus court entre deux points sur une surface courbe (telle que la Terre) est un arc d’un grand cercle. [4] Il est donc nécessaire de procéder à des calculs supplémentaires pour obtenir les distances en unités planaires (kilomètres ou milles). L’emploi d’un système de coordonnées géographique peut introduire par la suite des complications pour le développeur. Par exemple, Spatialite ne peut pas calculer des distances entre des géométries exprimées en système de coordonnées géographique. Par exemple, construire une requête pour trouver tous les points à mois de 5 kilomètres des frontières d’un département stocké sous forme de coordonnées WGS84. [5]
\nDes portions de la surface terrestre peuvent être projetées sur un plan bidimensionnel ou cartésien. Les systèmes de coordonnées projetés sont particulièrement adaptés pour les applications spécifiques à une région. Par exemple , si vous savez que votre base de données ne contiendra que des objets géométriques du Kansas du Nord, il est envisageable d’utiliser un système de projection spécifique à cette région. De plus, les systèmes de coordonnées projetés sont définis en unités cartésiennes (telles que les mètres ou les pieds) qui facilitent le calcul des distances.
\n\nRessources supplémentaires :
\nspatialreference.org: une base de données programmée en Django de systèmes de références spatiales.
The State Plane Coordinate System: un site Web présentant les divers systèmes de projection utilisés aux États-Unis. La plupart des données spatiales américaines existantes sont dans l’un de ces systèmes de coordonnées plutôt que dans un système de coordonnées géographique tel que WGS84.
spatial_indexLien vers cette rubrique#La valeur par défaut est True. Crée un index spatial pour le champ géométrique donné.
Les champs géométriques disposent d’options supplémentaires. Toutes les options suivantes sont facultatives.
\ndimLien vers cette rubrique#Cette option peut être utilisée pour personnaliser les dimensions de coordonnées du champ géométrique. Par défaut, il y a deux dimensions pour représenter des objets géométrique en 2D. Pour les moteurs spatiaux qui le gèrent, il est possible de définir cette option à 3 pour la prise en charge de la 3D.
\n\ngeographyLien vers cette rubrique#Si définie à True, cette option crée une colonne de base de données de type géographique plutôt que géométrique. Référez-vous à la section type géographique ci-dessous pour plus de détails.
Le type géographique fournit une prise en charge native des objets spatiaux représentés par des coordonnées géographiques (par ex. longitude/latitude WGS84). [6] Au contraire du plan utilisé par un type géométrique, le type géographique utilise une représentation sphérique de ses données. Les opérations de distance et de mesure effectuées sur une colonne géographique utilisent automatiquement des calculs sur les arcs de grands cercles et renvoient des unités linéaires. En d’autres termes, lorsque ST_Distance est appelée sur deux éléments de type géographique, une valeur en mètres est renvoyée (contrairement aux valeurs en degrés renvoyées lors de calculs sur des colonnes de type géométrique en WGS84).
Comme les calculs géographiques induisent plus d’opérations mathématiques, seul un sous-ensemble des recherches spatiales PostGIS sont disponibles pour le type géographique. En pratique, cela signifie qu’en plus des recherches de distance, seules les recherches spatiales supplémentaires suivantes sont disponibles pour les colonnes de type géographique :
\nPour plus d’informations, la documentation PostGIS contient une section instructive sur la façon de déterminer quand utiliser le type de données géographique au lieu d’un type géométrique.
\nGeoManagerLien vers cette rubrique#Le gestionnaire GeoManager est obligatoire afin de pouvoir utiliser les Méthodes GeoQuerySet dépréciées.
Notes de bas de page
\n\n