Suite

Intersection PostGIS et résumé des attributs


Je suis généralement un utilisateur de bureau ArcGIS, mais je souhaite commencer à utiliser davantage PostGIS et j'ai un très gros travail de traitement à faire. Je ne sais pas quelles fonctions utiliser, j'espère que quelqu'un pourra vous aider.

J'ai un jeu de données de polygones (plusieurs millions d'entités), basé sur un type de classification d'utilisation des terres/couverture des terres (20 catégories). J'ai un certain nombre de régions dans un autre ensemble de données.

Pour chacune des régions, j'aimerais connaître la superficie de chaque classification d'occupation du sol.

Dans ArcGIS (s'il s'agissait d'un jeu de données plus petit), j'imagine d'abord ajouter la région à chacun des polygones de la table attributaire à l'aide d'une jointure. Puis en utilisant « résumé » sur le tableau par région et par classification d'occupation du sol.

Vous ne savez pas par où commencer dans PostGIS / SQL.

Mettre à jour:

Wow merci cela a été d'une grande aide.

Il a fonctionné longtemps (44 heures !) et maintenant j'obtiens :

AVIS : TopologyException : a trouvé une intersection sans nœud entre LINESTRING (coords édités) et LINESTRING (coords edited) à (position edited) ERREUR : GEOS Intersection() a généré une erreur ! ********** Erreur ********** ERREUR : GEOS Intersection() a généré une erreur ! État SQL : XX000

Je suppose qu'il s'agit d'un problème dans les données d'origine - juste un cas d'examen des données d'origine ou puis-je d'abord vérifier la topologie pour l'ensemble des données ? Y a-t-il quelque chose à propos de l'acceptation de certaines erreurs/tolérances de traitement ?


En supposant que vous ayez la disposition de table suivante

landcover(id,type,the_geom) region(id,name,the_geom)

Les valeurs de superficie par type de couverture terrestre par région peuvent être calculées en utilisant

SELECT r.id, r.name, r.the_geom, l.type, Sum(ST_Area(ST_Intersection(l.the_geom,r.the_geom))) FROM landcover l, region r WHERE l.the_geom && r.the_geom GROUP by r .id, r.name, r.the_geom, l.type

ST_Intersection est utilisé pour tenir compte des polygones de couverture terrestre qui ne sont que partiellement dans une région.


Chapitre 4. Utilisation de PostGIS : gestion des données et requêtes

Les objets SIG pris en charge par PostGIS sont un sur-ensemble des « éléments simples » définis par l'OpenGIS Consortium (OGC). Depuis la version 0.9, PostGIS prend en charge tous les objets et fonctions spécifiés dans la spécification OGC "Simple Features for SQL".

PostGIS étend la norme avec la prise en charge des coordonnées 3DZ, 3DM et 4D.

4.1.1. OpenGIS WKB et WKT

La spécification OpenGIS définit deux manières standard d'exprimer des objets spatiaux : la forme Well-Known Text (WKT) et la forme Well-Known Binary (WKB). WKT et WKB incluent tous deux des informations sur le type de l'objet et les coordonnées qui forment l'objet.

Voici des exemples de représentations textuelles (WKT) des objets spatiaux des entités :

POLYGONE((0 0,4 0,4 ​​4,0 4,0 0),(1 1, 2 1, 2 2, 1 2,1 1))

CHAÎNE MULTILIGNE((0 0,1 1,1 2),(2 3,3 2,5 4))

MULTIPOLYGONE(((0 0,4 0,4 ​​4,0 4,0 0),(1 1,2 1,2 2,1 2,1 1)), ((-1 -1,-1 -2, -2 -2,-2 -1,-1 -1)))

GÉOMÉTRIECOLLECTION(POINT(2 3),LINESTRING(2 3,3 4))

La spécification OpenGIS exige également que le format de stockage interne des objets spatiaux inclue un identifiant de système de référencement spatial (SRID). Le SRID est requis lors de la création d'objets spatiaux à insérer dans la base de données.

Les entrées/sorties de ces formats sont disponibles via les interfaces suivantes :

Par exemple, une instruction d'insertion valide pour créer et insérer un objet géographique OGC serait :

4.1.2. PostGIS EWKB, EWKT et formulaires canoniques

Les formats OGC ne prennent en charge que les géométries 2D et le SRID associé n'est *jamais* intégré dans les représentations d'entrée/sortie.

Les formats étendus PostGIS sont actuellement un sur-ensemble d'OGC un (chaque WKB/WKT valide est un EWKB/EWKT valide), mais cela pourrait varier à l'avenir, en particulier si OGC sort un nouveau format en conflit avec nos extensions. Ainsi, vous NE DEVRIEZ PAS vous fier à cette fonctionnalité !

PostGIS EWKB/EWKT ajoute la prise en charge des coordonnées 3dm, 3dz, 4d et les informations SRID intégrées.

Des exemples de représentations textuelles (EWKT) des objets spatiaux étendus des entités sont les suivants.

SRID=32632POINT(0 0) -- XY avec SRID

SRID=4326MULTIPOINTM(0 0 0,1 2 1) -- XYM avec SRID

CHAÎNE MULTILIGNE((0 0 0,1 1 0,1 2 1),(2 3 1,3 2 1,5 4 1))

POLYGONE((0 0 0,4 0 0,4 4 0,0 4 0,0 0 0),(1 1 0,2 1 0,2 2 0,1 2 0,1 1 0))

MULTIPOLYGONE(((0 0 0,4 0 0,4 4 0,0 4 0,0 0 0),(1 1 0,2 1 0,2 2 0,1 2 0,1 1 0)),(( -1 -1 0,-1 -2 0,-2 -2 0,-2 -1 0,-1 -1 0)))

GEOMETRYCOLLECTIONM( POINTM(2 3 9), LINESTRINGM(2 3 4, 3 4 5) )

MULTICOURBE( (0 0, 5 5), CIRCULARSTRING(4 0, 4 4, 8 4) )

SURFACE POLYÉDRALE( ((0 0 0, 0 0 1, 0 1 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 1 0 0, 0 0 0)), ((0 0 0, 1 0 0, 1 0 1, 0 0 1, 0 0 0)), ((1 1 0, 1 1 1, 1 0 1, 1 0 0, 1 1 0)), (( 0 1 0, 0 1 1, 1 1 1, 1 1 0, 0 1 0)), ((0 0 1, 1 0 1, 1 1 1, 0 1 1, 0 0 1)) )

NIF( ((0 0 0, 0 0 1, 0 1 0, 0 0 0)), ((0 0 0, 0 1 0, 1 1 0, 0 0 0)) )

Les entrées/sorties de ces formats sont disponibles via les interfaces suivantes :

Par exemple, une instruction d'insertion valide pour créer et insérer un objet spatial PostGIS serait :

Les "formes canoniques" d'un type PostgreSQL sont les représentations que vous obtenez avec une simple requête (sans aucun appel de fonction) et celle qui est garantie d'être acceptée avec une simple insertion, mise à jour ou copie. Pour le type « géométrie » postgis, il s'agit de :

Par exemple, cette instruction lit EWKT et renvoie HEXEWKB dans le processus d'entrée/sortie ascii canonique :

4.1.3. SQL-MM Partie 3

La spécification spatiale SQL Multimedia Applications étend les fonctionnalités simples de la spécification SQL en définissant un certain nombre de courbes interpolées de manière circulaire.

Les définitions SQL-MM incluent les coordonnées 3dm, 3dz et 4d, mais ne permettent pas l'intégration d'informations SRID.

Les extensions de texte bien connues ne sont pas encore entièrement prises en charge. Des exemples de quelques géométries courbes simples sont présentés ci-dessous :

CHAÎNE CIRCULAIRE(0 0, 1 1, 1 0)

CHAÎNE CIRCULAIRE(0 0, 4 0, 4 4, 0 4, 0 0)

Le CIRCULARSTRING est le type de courbe de base, similaire à un LINESTRING dans le monde linéaire. Un seul segment nécessitait trois points, les points de début et de fin (premier et troisième) et tout autre point sur l'arc. L'exception à cette règle est pour un cercle fermé, où les points de départ et d'arrivée sont les mêmes. Dans ce cas, le deuxième point DOIT être le centre de l'arc, c'est-à-dire le côté opposé du cercle. Pour enchaîner des arcs ensemble, le dernier point de l'arc précédent devient le premier point de l'arc suivant, tout comme dans LINESTRING. Cela signifie qu'une chaîne circulaire valide doit avoir un nombre impair de points supérieur à 1.

COMPOUNDCURVE(CIRCULARSTRING(0 0, 1 1, 1 0), (1 0, 0 1))

Une courbe composée est une courbe continue unique qui comporte à la fois des segments incurvés (circulaires) et des segments linéaires. Cela signifie qu'en plus d'avoir des composants bien formés, le point final de chaque composant (sauf le dernier) doit coïncider avec le point de départ du composant suivant.

CURVEPOLYGON(CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0), (1 1, 3 3, 3 1, 1 1))

Exemple de courbe composée dans un polygone courbe : CURVEPOLYGON(COMPOUNDCURVE(CIRCULARSTRING(0 0,2 0, 2 1, 2 3, 4 3),(4 3, 4 5, 1 4, 0 0)), CIRCULARSTRING(1.7 1, 1,4 0,4, 1,6 0,4, 1,6 0,5, 1,7 1) )

Un CURVEPOLYGON est comme un polygone, avec un anneau extérieur et zéro ou plusieurs anneaux intérieurs. La différence est qu'un anneau peut prendre la forme d'une chaîne circulaire, d'une chaîne linéaire ou d'une chaîne composée.

Depuis PostGIS 1.4, PostGIS prend en charge les courbes composées dans un polygone de courbe.

MULTICOURBE((0 0, 5 5), CIRCULARSTRING(4 0, 4 4, 8 4))

Le MULTICURVE est une collection de courbes, qui peuvent inclure des chaînes linéaires, des chaînes circulaires ou des chaînes composées.

MULTISURFACE(CURVEPOLYGONE(CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),(1 1, 3 3, 3 1, 1 1)),((10 10, 14 12, 11 10, 10 10 ),(11 11, 11,5 11, 11 11,5, 11 11)))

Il s'agit d'un ensemble de surfaces, qui peuvent être des polygones (linéaires) ou des polygones courbes.

PostGIS antérieur à 1.4 ne prend pas en charge les courbes composées dans un polygone de courbe, mais PostGIS 1.4 et versions ultérieures prennent en charge l'utilisation de courbes composées dans un polygone de courbe.

Toutes les comparaisons à virgule flottante dans l'implémentation SQL-MM sont effectuées avec une tolérance spécifiée, actuellement 1E-8.


Les fonctions données ci-dessous sont des fonctions PostGIS conformes à la norme SQL/MM 3

SQL-MM définit le SRID par défaut de tous les constructeurs de géométrie comme 0. PostGIS utilise un SRID par défaut de -1.

    - Renvoie vrai si deux géométries 3D sont à une distance 3D donnée Cette méthode implémente la spécification SQL/MM. SQL-MM ? - Renvoie la distance minimale cartésienne 3D (basée sur la référence spatiale) entre deux géométries en unités projetées. Cette méthode implémente la spécification SQL/MM. SQL-MM ? - Renvoie vrai si deux géométries se coupent spatialement en 3D - uniquement pour les points, les chaînes de lignes, les polygones, la surface polyédrique (aire). Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : ? - Ajoutez une nouvelle arête et, si ce faisant, elle divise une face, modifiez la face d'origine et ajoutez une nouvelle face. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.13 - Ajoutez une nouvelle arête et, si ce faisant, elle divise une face, supprimez la face d'origine et remplacez-la par deux nouvelles faces. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.12 - Ajoute une arête isolée définie par une chaîne géométrique à une topologie reliant deux nœuds isolés existants anode et un autre nœud et renvoie l'ID de l'arête de la nouvelle arête. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.4 - Ajoute un nœud isolé à une face dans une topologie et renvoie le nodeid du nouveau nœud. Si face est nul, le nœud est toujours créé. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Net Routines : X+1.3.1 - Renvoie l'aire d'une géométrie polygonale. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 8.1.2, 9.5.3 - Renvoie la représentation binaire bien connue (WKB) de la géométrie/géographie sans les métadonnées SRID. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 5.1.37 - Renvoie la représentation Well-Known Text (WKT) de la géométrie/géographie sans métadonnées SRID. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.25 - Renvoie la limite d'une géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.14 - Renvoie une géométrie couvrant tous les points à une distance donnée d'une géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.17 - Renvoie le centre géométrique d'une géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 8.1.4, 9.5.5 - Modifie la forme d'une arête sans affecter la structure de la topologie. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine X.3.6 - Renvoie vrai si et seulement si aucun point de B ne se trouve à l'extérieur de A, et qu'au moins un point de l'intérieur de B se trouve à l'intérieur de A. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.31 - Calcule l'enveloppe convexe d'une géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.16 - Renvoie la dimension des coordonnées d'une géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.3 - Ajoute une collection de géométries à une topologie vide donnée et renvoie un message détaillant le succès. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine -- X.3.18 - Renvoie vrai si deux géométries ont certains, mais pas tous, des points intérieurs en commun. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.29 - Convertit une géométrie contenant des courbes en une géométrie linéaire. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 7.1.7 - Renvoie une géométrie représentant la partie de la géométrie A qui n'intersecte pas la géométrie B. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.20 - Renvoie la dimension topologique d'une géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.2 - Renvoie vrai si deux géométries ne se coupent pas spatialement (elles n'ont aucun point commun). Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.26 - Renvoie la distance entre deux valeurs géométriques ou géographiques. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 5.1.23 - Renvoie le dernier point d'un LineString ou CircularLineString. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 7.1.4 - Renvoie une géométrie représentant la boîte englobante d'une géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.15 - Renvoie true si deux géométries incluent le même ensemble de points dans l'espace. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.24 - Renvoie une chaîne de ligne représentant l'anneau extérieur d'un polygone. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 8.2.3, 8.3.3 - Renvoie une valeur ST_Geometry spécifiée à partir de la représentation GML. Il s'agit d'un alias pour ST_GeomFromGML Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.50 (sauf pour le support des courbes). - Crée une collection Geometry à partir de la collection WKT avec le SRID donné. Si le SRID n'est pas fourni, sa valeur par défaut est 0. Cette méthode implémente la spécification SQL/MM. - Renvoie une valeur ST_Geometry spécifiée à partir de la représentation de texte bien connu (WKT). Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.40 - Crée une instance de géométrie à partir d'une représentation géométrique binaire connue (WKB) et d'un SRID facultatif. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.41 - Renvoie une valeur ST_Geometry spécifiée à partir de la représentation de texte bien connue (WKT). Il s'agit d'un nom d'alias pour ST_GeomFromText Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.40 - Renvoie le Nième élément de géométrie d'une collection de géométries. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 9.1.5 - Renvoie le type SQL-MM d'une géométrie sous forme de texte. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 5.1.4 - Renvoie un ensemble d'arêtes ordonnées qui délimitent une face. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.5 - Renvoie le polygone dans la topologie donnée avec l'identifiant de face spécifié. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.16 - Crée un nouveau schéma de topologie et enregistre ce nouveau schéma dans la table topology.topology et détaille le résumé du processus. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.17 - Renvoie le Nième anneau intérieur (trou) d'un polygone. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 8.2.6, 8.3.5 - Renvoie une géométrie représentant la partie partagée des géométries A et B. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.18 - Renvoie vrai si deux géométries/géographie se coupent spatialement en 2D (ont au moins un point en commun). Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.27 - Teste si les points de début et de fin d'une chaîne de ligne coïncident. Pour un PolyhedralSurface teste s'il est fermé (volumétrique). Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 7.1.5, 9.3.3 - Teste si une géométrie est vide. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 5.1.7 - Teste si une LineString est fermée et simple. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 7.1.6 - Teste si une géométrie n'a pas de points d'auto-intersection ou d'auto-tangence. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.8 - Teste si une géométrie est bien formée en 2D. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 5.1.9 - Renvoie la longueur 2D d'une géométrie linéaire. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 7.1.2, 9.3.4 - Crée une géométrie à partir d'une représentation WKT avec le SRID donné. Si le SRID n'est pas fourni, sa valeur par défaut est 0. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 7.2.8 - Crée un LINESTRING à partir de WKB avec le SRID donné Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 7.2.9 - Crée une géométrie à partir de WKB avec le SRID donné. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 7.2.9 - Renvoie la coordonnée M d'un point. Cette méthode implémente la spécification SQL/MM. - Renvoie une valeur ST_MultiLineString spécifiée à partir de la représentation WKT. Cette méthode implémente la spécification SQL/MM.SQL-MM 3: 9.4.4 - Crée une géométrie à partir de WKT avec le SRID donné. Si le SRID n'est pas fourni, sa valeur par défaut est 0. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 9.2.4 - Crée une géométrie multipolygone à partir de WKT avec le SRID donné. Si le SRID n'est pas fourni, sa valeur par défaut est 0. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 9.6.4 - Guérit deux arêtes en supprimant le nœud qui les relie, en modifiant la première arête et en supprimant la deuxième arête. Renvoie l'identifiant du nœud supprimé. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.9 - Divisez un tronçon en créant un nouveau nœud le long d'un tronçon existant, en modifiant le tronçon d'origine et en ajoutant un nouveau tronçon. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.9 - Déplace un nœud isolé dans une topologie d'un point à un autre. Si une nouvelle géométrie de point existe en tant que nœud, une erreur est générée. Renvoie la description du déplacement. Cette méthode implémente la spécification SQL/MM. SQL-MM : Routines Topo-Net : X.3.2 - Guérit deux arêtes en supprimant le nœud les reliant, en supprimant les deux arêtes et en les remplaçant par une arête dont la direction est la même que la première arête fournie. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.9 - Divisez une arête en créant un nouveau nœud le long d'une arête existante, en supprimant l'arête d'origine et en la remplaçant par deux nouvelles arêtes. Renvoie l'identifiant du nouveau nœud créé qui rejoint les nouvelles arêtes. Cette méthode implémente la spécification SQL/MM. SQL-MM : Routines Topo-Net : X.3.8 - Renvoie le nombre d'éléments dans une collection de géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 9.1.4 - Renvoie le nombre d'anneaux intérieurs (trous) d'un polygone. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 8.2.5 - Renvoie le nombre de faces sur une surface polyédrique. Renvoie null pour les géométries non polyédriques. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : ? - Renvoie le nombre de points dans un LineString ou CircularString. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 7.2.4 - Renvoie vrai si deux géométries représentent la même géométrie et ont des points dans le même ordre directionnel. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.43 - Renvoie vrai si deux géométries se coupent et ont la même dimension, mais ne sont pas complètement contenues l'une dans l'autre. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 5.1.32 - Renvoie la Nième géométrie (face) d'une PolyhedralSurface. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : ? - Renvoie la longueur de la limite d'une géométrie polygonale ou d'une géographie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 8.1.3, 9.5.4 - Crée un point avec les valeurs de coordonnées données. Alias ​​pour ST_MakePoint. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 6.1.2 - Fait un point Géométrie à partir de WKT avec le SRID donné. Si le SRID n'est pas fourni, il est par défaut inconnu. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 6.1.8 - Crée une géométrie à partir de WKB avec le SRID donné Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 6.1.9 - Renvoie le Nième point dans le premier LineString ou LineString circulaire dans une géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 7.2.5, 7.3.5 - Renvoie un point garanti dans un polygone ou sur une géométrie. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 8.1.5, 9.5.6. Selon les spécifications, ST_PointOnSurface fonctionne pour les géométries de surface (POLYGONES, MULTIPOLYGONS, CURVED POLYGONS). PostGIS semble donc étendre ce que la spécification permet ici. La plupart des bases de données Oracle,DB II, ESRI SDE semblent ne prendre en charge cette fonction que pour les surfaces. SQL Server 2008 comme PostGIS prend en charge toutes les géométries courantes. - Crée un polygone à partir d'un LineString avec un SRID spécifié. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 8.3.2 - Crée une géométrie à partir de WKT avec le SRID donné. Si le SRID n'est pas fourni, sa valeur par défaut est 0. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 8.3.6 - Teste si deux géométries ont une relation topologique correspondant à un modèle de matrice d'intersection donné, ou calcule leur matrice d'intersection Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.25 - Supprime une arête et, si l'arête supprimée sépare deux faces, supprime l'une d'entre elles et modifie l'autre pour prendre l'espace des deux. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.15 - Supprime une arête et, si l'arête supprimée sépare deux faces, supprime les faces d'origine et remplace-les par une nouvelle face. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X.3.14 - Supprime un bord isolé et renvoie la description de l'action. Si le bord n'est pas isolé, une exception est levée. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X+1.3.3 - Supprime un nœud isolé et renvoie la description de l'action. Si le nœud n'est pas isolé (est le début ou la fin d'une arête), une exception est alors levée. Cette méthode implémente la spécification SQL/MM. SQL-MM : Topo-Geo et Topo-Net 3 : Détails de la routine : X+1.3.3 - Renvoie l'identifiant de référence spatiale pour la ST_Geometry tel que défini dans la table spatial_ref_sys. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 5.1.5 - Retourne le premier point d'une LineString. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 7.1.3 - Renvoie une géométrie représentant les portions des géométries A et B qui ne se coupent pas. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.21 - Renvoie vrai si deux géométries ont au moins un point en commun, mais que leurs intérieurs ne se coupent pas. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.28 - Renvoie une nouvelle géométrie avec ses coordonnées transformées dans un autre système de référence spatiale. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.6 - Renvoie une géométrie représentant l'union d'ensembles de points des géométries d'entrée. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.19 le z-index (élévation) lorsque des polygones sont impliqués. - Renvoie une valeur ST_Geometry spécifiée à partir de la représentation binaire connue (WKB). Il s'agit d'un nom d'alias pour ST_GeomFromWKB qui ne prend aucun srid. Cette méthode implémente la spécification SQL/MM. SQL-MM 3: 5.1.36 - Renvoie une valeur ST_Geometry spécifiée à partir de la représentation de texte bien connue (WKT). Il s'agit d'un alias pour ST_GeomFromText Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.34 - Renvoie vrai si la géométrie A est complètement à l'intérieur de la géométrie B Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 5.1.30 - Renvoie la coordonnée X d'un point. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 6.1.3 - Renvoie la coordonnée Y d'un point. Cette méthode implémente la spécification SQL/MM. SQL-MM 3 : 6.1.4 - Renvoie la coordonnée Z d'un point. Cette méthode implémente la spécification SQL/MM.

J'ai mentionné dans les commentaires que vous pourriez utiliser st_join . Cependant, cela peut ne pas vous donner le résultat souhaité. Dans la bibliothèque sf, il y a les prédicats binaires géométriques, tels que ?st_intersects , et les opérations géométriques telles que ?st_intersection

Les prédicats renvoient une matrice creuse (par défaut) ou dense vous indiquant avec quelle géométrie de y chaque géométrie de x se croise. Si vous l'utilisez dans st_join , il renverra les géométries (d'origine) qui se croisent, plutôt que la matrice creuse.

Alors que les opérations (par exemple st_intersection ) calculeront l'intersection et renverront de nouvelles géométries.

Exemple d'utilisation

Les prédicats ( st_intersects ) peuvent être utilisés à l'intérieur de st_join , et ils renverront les géométries d'origine qui « se croisent »

Dans ce cas, cela donne un seul type d'objet

Mais vous devez décider si le résultat de st_intersect est ce que vous recherchez ou si vous avez besoin des nouvelles géométries données par st_intersection .

Lectures complémentaires

les informations sur chaque jointure sont sur le blog sf.

les prédicats spatiaux et des exemples de ce que font les différentes opérations sont sur wikipedia (avec quelques bonnes illustrations)

Remerciements à l'utilisateur @lbussett pour sa description de la différence entre st_intersect et st_intersection


3 - Utilisation de PostGIS Raster

Comme le type "geometry" de PostGIS, le type "raster" de PostGIS est un nouveau type PostgreSQL. Cela signifie que chaque raster ou tuile raster est stocké sous forme de ligne de données dans une table de base de données PostgreSQL. C'est un type complexe, intégrant des informations sur le raster lui-même (largeur, hauteur, nombre de bandes, type de pixel pour chaque bande et valeur nodata pour chaque bande) ainsi que sa géolocalisation (taille de pixel, centre de pixel supérieur gauche, rotation et SRID).

3.1.1 - Justification du raster PostGIS

PostGIS Raster a été conçu avec de nombreux objectifs, pour accueillir une myriade de structures de jeux de données et une diversité d'applications :

Objectif 1 : Simplicité, Complémentarité et Fonctionnalité - PostGIS Raster fournit un type "raster" qui complète le type "géométrie" vectoriel PostGIS existant. Cette nouvelle extension propose des opérateurs et des fonctions similaires à ceux disponibles avec le type de géométrie existant. Ils fonctionnent de la même manière conviviale, mais sont associés à une structure de données géospatiales matricielles pour prendre en charge l'utilisation de rasters. PostGIS Raster comprend également un chargeur simple pour importer de nombreux formats raster dans la base de données.

Objectif 2 : Intégration transparente avec le type de géométrie PostGIS - PostGIS Raster permet aux opérateurs et fonctions PostGIS de fonctionner de manière transparente sur les types raster et géométriques, de sorte que les utilisateurs :

  • peuvent utiliser leurs connaissances préalables de PostGIS en général, et de ses opérateurs et fonctions de type géométrique, lors de la création de requêtes SQL
  • attendez-vous à des comportements similaires lors de l'utilisation de ces opérateurs et fonctions avec le type raster sans avoir à considérer si leurs données sont sous forme vectorielle ou matricielle
  • attendez-vous à ce que les applications existantes fonctionnent avec de nouvelles données chargées sous forme de rasters sans (beaucoup) de modifications (dans une certaine limite conceptuelle).

Cela fait de PostGIS Raster un niveau d'abstraction, non seulement sur le format raster (comme GDAL) ou sur le format vectoriel (comme OGR), mais plus généralement sur les deux structures de données les plus utilisées dans l'industrie géospatiale (raster ET vecteur). Même si de nombreuses opérations effectuées sur un objet vectoriel (ex. travaillant sur des objets vectoriels, nous pensons, et nous démontrerons au fur et à mesure que nous étendrons PostGIS Raster à l'avenir, que la plupart des opérations ont leur équivalent à la fois dans les mondes raster et vectoriel (par exemple ST_Intersections(), ST_Accum(), ST_Area(), ST_MapAlgebra() ), même si cela ne paraît pas évident à première vue.

Nous pensons que fournir un paradigme unique (SQL) pour traiter à la fois les rasters et les vecteurs devrait permettre aux développeurs d'écrire de meilleures applications SIG, en simplifiant les interfaces utilisateur graphiques et en adoucissant les courbes d'apprentissage. Les développeurs devraient être en mesure de créer une interface utilisateur graphique unique pour gérer les données raster et vectorielles, obligeant les utilisateurs à n'apprendre qu'un seul ensemble d'opérateurs pour travailler avec des données vectorielles et des données raster, au lieu de deux. Nous pensons que cela devrait généralement améliorer l'expérience des utilisateurs avec les applications géospatiales et leur permettre de se concentrer sur de vrais problèmes géographiques plutôt que de se débattre avec des formats et des structures de données.

Nous pensons également que cette approche est conforme (au moins en philosophie) à la spécification ISO 19123 "Abstract Specification Schema for Coverage Geometry and Functions" (à ne pas confondre avec l'OCG Web Coverage Service) dans laquelle une couverture peut être représentée comme un une couche de points, une couche de polygones, une couche TIN ou une couche raster, et dans laquelle toute valeur de position de la couverture est accessible sans avoir à connaître la structure de données sur laquelle la couverture est basée.

Objectif 3 : Flexibilité du stockage (stockage in-db & out-db) - PostGIS Raster permet à l'utilisateur de simplement « enregistrer » les métadonnées de base (type de pixel, avec, hauteur, géoréférencement, etc.) des images stockées dans le système de fichiers, sans avoir à charger réellement leurs valeurs de données dans la base de données. De cette façon, les applications Web ou de bureau :

  • n'ont pas à récupérer les images de la base de données mais peuvent à la place y accéder directement à partir du système de fichiers (par exemple sous forme de fichiers JPEG)
  • peut néanmoins utiliser la plupart des opérateurs et fonctions PostGIS Raster sur ces rasters, de manière transparente.

Il s'agit d'un stockage "out-db" par opposition au stockage "in-db" plus naturel.

Objectif 4 : Interopérabilité – PostGIS Raster utilise GDAL ( ​ http://www.gdal.org/) comme connecteur principal vers les fichiers raster du système de fichiers. GDAL est impliqué lors du chargement des rasters dans la base de données (à l'aide du chargeur) et lors de l'utilisation de rasters out-db. Il permet à PostGIS Raster de travailler avec près d'une centaine de formats de fichiers différents. (Pour une liste complète des formats de fichiers pris en charge, voir http://www.gdal.org/formats_list.html). (GDAL est également utilisé pour implémenter certaines fonctions de traitement raster, mais c'est une autre affaire.)

Les objectifs 2 et 3 répondent à l'idée la plus discutée selon laquelle "le stockage des rasters dans la base de données est plus lent et inutile s'il ne bénéficie pas des fonctionnalités spécifiques des bases de données". L'Objectif 2 fait de PostGIS Raster une boîte à outils analytique, allant au-delà du simple format de données. L'objectif 3 garantit la flexibilité du stockage, l'efficacité de la récupération et la transparence pour les utilisateurs. Les deux objectifs bénéficient grandement de l'indexation des données raster dans la base de données.

Nous pensons que ces fonctionnalités supplémentaires (par rapport aux autres implémentations de raster dans la base de données) font de PostGIS Raster bien plus qu'un simple nouveau format raster, mais aussi un complément nécessaire à PostGIS.

3.1.2 - Implémentation du raster PostGIS

Pour atteindre ces objectifs, PostGIS Raster implémente une structure de données raster minimaliste mais complète, et adopte un schéma relationnel simple à type unique et à table unique. Cette structure de données est très similaire à la structure de type vecteur géométrique PostGIS, et très différente, par exemple, des types raster Oracle Spatial SDO_GEORASTER et SDO_RASTER.

  • Un seul type raster - Dans PostGIS Raster, il n'existe pas de raster et ses tuiles raster ou d'image et ses tuiles d'images. Même si des attributs de raster uniques peuvent être considérés comme des tuiles d'une couverture ou des tuiles d'une image, tout attribut de type raster est un raster géoréférencé complet et autosuffisant. Il n'est pas nécessairement lié à d'autres rasters dans la même table, et pas nécessairement situé dans une grille spécifique. Ce choix rend tout très simple et flexible, laissant les utilisateurs et les applications décider comment ils structurent leurs données et comment ils nomment leurs éléments raster (rasters, images, bitmap, blocs, tuiles, etc…).
  • Un schéma relationnel à table unique – Similarly, in PostGIS Raster there is not one table for storing the raster data (like Oracle Spatial SDO_RASTER) and another table for storing the georeference and the metadata (like Oracle Spatial SDO_GEORASTER). Everything is stored in a single raster attribute, and raster attributes composing a table are not necessarily related to each other to form a significant coverage.

These choices make the PostGIS raster structure very similar to the existing PostGIS vector structure in which a layer can be geometrically topological or not, depending on the user data and their choices of application.

This also means, contrary to most raster formats, that raster attributes from the same table:

  • may be of different size. Par exemple. one raster can be 256 pixels wide and 256 pixels high while another can be 64 pixels wide and 64 pixels high.
  • may "snap" to different grid. Par exemple. the upper left corner of a raster with a pixel size of 10m can be at 0,0 in a coordinate system with a map unit in meters, and the upper left corner of another raster with the same pixel size in the same coordinate system can be at 0,1.25. This means that pixels of different raster attributes are not necessarily grid aligned.
  • may overlap, like polygons in a vector layer may overlap. This is fundamental to implementing meaningful vector to raster conversions in which all attributes accompanying a vector feature are conserved in the resulting raster table. Par exemple. 10 lake vector features with attributes like "name, type, area, perimeter, etc…" are converted to 10 lake raster features with the same attributes. In this case, even if the vector features and the “withdata values” part of the resulting raster features do not necessarily overlap, the "nodata values" of the raster features will overlap.

These characteristics enable easy integration with vectors, but the flexibility also allows the loading of raster assemblages that are not necessarily suitable for geoanalysis. As with vector layers, you are responsible to ensure that your layer meets the minimum topological requirements for analysis. The ideal case is when all the raster tiles of a continuous layer are the same size, snap to the same grid and do not overlap.

Par conséquent, un single attribute of type raster can store:

  • a "complete image" (e.g. Landsat),
  • an image "tile",
  • a "raster object" a new kind of raster object introduced by PostGIS Raster resulting from the rasterization of a vector feature.

All these objects are different terminologies and concepts related to the general concept of "raster". We will use the latter term throughout the rest of this documentation.

Similarly, a table with a column of type raster may be seen, depending on the structure and the relationships between the raster objects it contains, as storing (Table 1 provides a summary of the characteristics inherent to each arrangement, and figure 1 provides a corresponding graphical representation of each one.):

une) an image warehouse of untiled and (possibly) unrelated images. These images may or may not overlap since every image has its own georeference. They may also have no georeference at all.

b) an irregularly tiled raster coverage. It might not necessarily be rectangular, there might be some missing tiles, and they might be different sizes. Tiles should not overlap.

c) a regularly tiled raster coverage. It might not necessarily be rectangular, there might be some missing tiles, and the tiles should be the same size. Tiles should not overlap.

ré) a rectangular regularly tiled raster coverage. It is necessarily rectangular, there are no missing tiles, they are all the same size and they do not overlap.

e) a tiled image. It is necessarily rectangular, there are no missing tiles, they are all the same size, and they do not overlap. This type is different from type d) in that it does not represent a complete coverage other images forming the rest of the coverage are stored as other tables of tiled images. This structure is not very practical from a GIS analytical point of view since any operations applied to the coverage must also be applied to every table.

F) a raster object coverage resulting from the rasterization of a vector coverage. Each vector feature becomes a small raster with the same extent as the original vector feature. This type of coverage is not necessarily complete, nor rectangular tiles should be of different sizes and might overlap. It all depends on the characteristics of the vector layer being rasterized. An exhaustive (or continuous) layer of mutually exclusive geometries (without gaps or holes like a forest cover) would result in a raster object coverage in which significant pixels (withdata values) would not overlap, but non-significant pixels (nodata values) would. On the other end of the spectrum, a discontinuous layer of mutually exclusive geometries (like a lake or building layer) would result in a coverage of mostly disjoint raster objects.

Table 1 - Characteristics of different possible raster table arrangements in PostGIS Raster

Arrangement Global shape of
composing raster
Missing tiles
possible
Same size
carrelage
Tile overlap
possible
Form a
coverage?
a) image warehouse of untiled and unrelated images quelconque no tiles no tile Oui Non
b) irregularly tiled raster coverage quelconque Oui non non Oui
c) regularly tiled raster coverage quelconque Oui Oui non Oui
d) rectangular regularly tiled raster coverage strictly rectangular non Oui non Oui
e) tiled image strictly rectangular non Oui non not as a single table
f) raster object coverage quelconque no real tiles no real tiles Oui Oui

Figure 1 - Different possible raster table arrangements in PostGIS Raster

All these arrangements are possible, and as for a geometry layer which can be implicitly topological or not, PostGIS Raster does not impose one over the other (even though types c) and d) and f) are the most practical for a GIS analyst). The fact that users of a database might (contrary to a raster file format) add or delete rows (or “tiles”) in a table, along with the fact that we must support variable-sized tiles (for vector to raster conversion), makes it very difficult to enforce a certain type of configuration.

Regularly Blocked Table

You can inform PostGIS that the raster layer you are loading meets certain useful criteria by adding the –k option to the gdal2wktraster.py Python loader. This will set the "regular_blocking" attribute of the raster_columns table to vrai. It implies that:

  • All loaded tiles have the same width and height,
  • All tiles do not overlap and their upper left corners follow a regular block grid,
  • The global extent of the layer is rectangular and not rotated.

Some blocks (or tiles) can be missing in a regularly blocked table. Missing tiles are assumed to be filled with the proper nodata value for each band as determined in the raster_columns table.

This regular tiling (or regular blocking) is expected from arrangements c) d) and e) in figure 1. PostGIS Raster provides this mechanism because raster applications are often optimized to deal with these arrangements. There is, however, no mechanism to enforce (constrain) these criteria and, as mentioned above, adding, modifying or deleting a row from the table might break this regular blocking, and the regular_blocking attribute will not be automatically updated.

Structure of the "raster" Type

Like the geometry type, the raster type is a complex PostgreSQL type composed of many attributes accessible using various functions. A raster attribute may be composed of many bands sharing a common size, pixel size and georeference. Each band has a pixel type and may have a nodata value.

Table 2 summarizes the composition of a raster type.

Table 2 - Structure of a raster type

Attribut La description Stockage Accessible with function.
version WKB format version (now 0). unsigned 16 bit integer Not accessible.
number of bands Number of raster bands stored in the raster. unsigned 16 bit integer ST_NumBands()
largeur Width of the raster. unsigned 16 bit integer ST_Width()
la taille Height of the raster. unsigned 16 bit integer ST_Height()
Georeference information
pixelsizex Pixel size in the x-direction in the same map units as the coordinate system. Same as parameter A in a world file. 64 bit double ST_PixelSizeX()
pixelsizey Pixel size in the y-direction in the same map units as the coordinate system. Same as parameter E in a world file. 64 bit double ST_PixelSizeY()
upperleftx X-coordinate of the center of the upper left pixel. Same as parameter C in a world file. 64 bit double ST_UpperLeftX()
upperlefty Y-coordinate of the center of the upper left pixel. Same as parameter F in a world file. 64 bit double ST_UpperLeftY()
rotationx Rotation about x-axis. Same as parameter B in a world file. 64 bit double ST_RotationX()
rotationy Rotation about y-axis. Same as parameter D in a world file. 64 bit double ST_RotationY()
srid Spatial reference id. 32 bit integer ST_SRID()
Band information (one set per band)
isoffline Flag specifying if the band data is stored in the database or as a file in the file system. 1 bit If ST_BandPath() return an empty string, the data is stored in the database.
hasnodatavalue Flag specifying if the stored nodatavalue is significant or not. 1 bit ST_BandHasNoDataValue()
pixeltype Pixel type for this band. 4 bits ST_BandPixelType()
nodatavalue Nodata value for the band. Depend on band pixel type. ST_BandNodataValue()
Band data (one set per band) for in-db raster
values[] Value of each pixel. Depends on band pixel type. ST_ Value()
Band data (one set per band) for out-db raster
bandnumber Number of the out-db band. unsigned 8 bit integer Not accessible yet.
chemin Path to the out-db raster file. string ST_BandPath()

  • "unsigned 8 bits integer" are 0 and 255.
  • "unsigned 16 bits integer" are 0 and 65535.
  • "32 bits integer" are -2 147 483 648 and 2 147 483 647.
  • "64 bits double" are -1.7*10-308 and 1.7*10308.

PostGIS Raster is expressed in different forms, depending on the level at which it is referred:

  • WKT - "Well Known Text" refers to the human readable text format used when inserting a raster with ST_RasterFromText() (not yet implemented) and retrieving a raster with ST_AsText() (not yet implemented). This format can result in the loss of precision when used with floating point values. This is why the HEXWKB form is preferred when importing/exporting in textual form.
  • WKB - "Well Known Binary" refers to the binary equivalent of the WKT. It is used when inserting a raster using ST_RasterFromWKB() and retrieving a raster using ST_AsBinary().
  • HEXWKB - "Hexadecimal WKB" is an exact hexadecimal representation of the WKB form. It is also called the "canonical" form. It is what you get from the loader (gdal2wktraster.py), what is accepted by the raster type input function (ST_Raster_In), and what you get when outputting the value of a raster field without conversion (e.g. SELECT rast FROM table).
  • Serialized - The "serialized" format is what is written to the filesystem by the database. It differs from WKB in that it does not have to store the endianness of the data and that it must be aligned. Serializing is the action of writing data to the database file, deserializing is the action of reading this data.

The raster_columns Table

Like the PostGIS "geometry_column" table, the PostGIS Raster "raster_columns" table is a way for applications to get a quick overview of which tables have a raster column, and to get the main characteristics (metadata) of the rasters stored in these columns. Applications should maintain this table using the AddRasterColumn() and DropRasterColumn() functions, as there is no automatic mechanism in the database to keep this table up to date with every raster column created or deleted.

Table 3 summarizes the attributes of the raster_columns table.

Attribut PostgreSQL Type La description
r_table_catalog character varying(256) Name of the catalog containing the table. This attribute exists only to follow the geometry_column table schema. It is generally left empty.
r_table_schema character varying(256) Name of the schema containing the table. Generally equal to “public”.
r_table_name character varying(256) Name of the table containing a column of type raster.
r_column character varying(256) Name of the raster column in the table.
srid entier ID of the spatial reference system used for the raster column in this table. It is a foreign key reference to the PostGIS spatial_ref_sys table.
pixel_types array[varchar] Array of pixel types one for every band. Index for first band is 1. Types are expressed as varchar (string) values:
"1BB" = 1-bit boolean
"2BUI" = 2-bit unsigned integer
"4BUI" = 4-bit unsigned integer
"8BSI" = 8-bit signed integer
"8BUI" = 8-bit unsigned integer
"16BSI" = 16-bit signed integer
"16BUI" = 16-bit unsigned integer
"32BSI" = 32-bit signed integer
"32BUI" = 32-bit unsigned integer
"32BF" = 32-bit float
"64BF" = 64-bit float
out_db array[boolean] Array of flags for in-db or out-db storage one per band. True when raster data is not stored in the database but resides as files in the filesystem. Paths to these files (one per row) are determined by ST_BandPath(). Index for first band is 1.
regular_blocking booléen Flag specifying that the regular blocking constraint is enforced for this table.
nodata_values array[double] Array of nodata values one for each band. Each nodata value is stored as a double (even when the pixel type is integer). Index for first band is 1.
pixelsize_x double Pixel size of the raster in the x-direction. In the units of the coordinate system determined by srid.
pixelsize_y double Pixel size of the raster in the y-direction. In the units of the coordinate system determined by srid.
blocksize_x entier Width of a block of raster data when regular_blocking is set to true. NULL otherwise.
blocksize_y entier Height of a block of raster data when "regular_blocking" is set to true. NULL otherwise.
Le degré geometry Polygon geometry encompassing all raster rows of this table. NULL if predefined bounds are not known. When "regular_blocking" is set to true this polygon is a simple rectangle. In other cases it might be an irregular polygon.

3.1.3 - Storing in-db raster or registering out-db raster?

One of the major PostGIS Raster features is the ability to store raster data in the database or merely register them as external files residing in the filesystem. When registering a raster, only the raster metadata are stored in the database (width, height, number of band, georeference and path to the actual raster file), not the values associated with the pixels. Registering is done via the loader’s –R option.

Out-db raster is targeted at read-only applications. It has the following advantages:

  • Access Speed - Speeds up the reading (and transmission) of web-ready rasters (JPEG, GIF, PNG) files for web applications as there is no need to convert them from the PostGIS raster type to a web friendly format.
  • Seemless SQL Operators and Functions – All the operators and functions (except those involving write operations to the raster like ST_SetValue()) work seamlessly with out-db rasters.
  • Simplified Backup – Rasters residing in the filesystem can be backed up once forever since they are not expected to be edited.
  • Faster Database Loading – Initial table creation is faster since data do not have to be loaded/copied in the database.

In-db raster is targeted at editing and analysis applications. It has the following advantages:

  • Fast Analysis – Analysis operations involving pixel per pixel interpretation (ST_AsPolygon(), ST_Intersections(), etc…) are faster on in-db rasters since there is no need to read and extract the actual data from a JPEG or a TIFF format.
  • Single storage solution – Provide a single vector/raster datasets storage solution. There is no need to backup the raster datasets separately from the vector datasets.
  • Multi-Users Edition – The database handles concurrent editing on raster only for in-db rasters.

NEVER, EVER use Debezium versions between 1.2.2 and 1.3.0. Those versions come with a bug which is hard to understand for anoyne who isn’t a Postgres expert, but its consequences are simple and dangerous : using such buggy Debezium version will take the master database down sooner or later. This is because Debezium will consume data changes, but won’t confirm the consumption to the database server. The server will retain all WAL segments since replication slot creation, and you will eventually run out of disk space (or money, if you use some pay-as-you-go storage like Amazon EFS or keep adding new disks).

When Debezium fails to connect, it returns a “Could not obtain encoding for database …” error message. Usually it has NOTHING to do with encoding, it just means that it couldn’t connect. Check the Postgres log for details – it might be a wrong password or no pg_hba.conf rule. If the database log is clean, look for network issues.


Discussion

Conceptually, this study offers a new way of examining and aggregating individual GPS trajectories. First, this platform supports research that examines individual’s travel trajectories. By focusing on daily activity places instead of the arbitrary residential neighborhood, this approach represents improvements in capturing the environmental exposure associated with behavioral and health outcomes. Moreover, based on the collected positioning points, we computed a continuous probability surface to quantify the likelihood of individuals being at certain locations.

Another methodological contribution of this study is to tie multi-dimensional attributes, e.g. the step and duration surfaces with travel patterns. In human–environment research, methods have been proposed to delineate the contextual areas to which individuals expose based on GPS points, but limited attention has been paid to identifying walking behavior and recording the duration of activities in specific environmental context. As a result, the entire activity space is usually given equal consideration when analyzing the environmental associates of behavior. However, as we know from previous research, the health and behavioral outcomes vary based on type of activity, intensity, and duration [2]. Our approach provides data regarding steps and duration of activity in the different tiles that could be examined in relation to different environmental characteristics.

Also, the aggregation process helps safeguard the privacy issue associated with personal location data. Researchers and individual users can select to release data at the level where private information cannot be traced, which is particularly useful in generating visualizations to show the spatial patterns of travel behavior.

Finally, this proposed platform combines a number of GPS data collection, visualization and analysis functionalities for research and everyday use. The technical issues regarding transforming and converting data across platforms present challenge for researchers and limits the use of GPS tracking in a variety of research. Our platform, however, supports processes that involves the collection of individual data, aggregation based on specific research goals and analytical needs.

There are several limitations in this study. First, because the possible tiles that connect origin and destination were interpolated based on the consecutive location points, locations where the signal is weak or the participant is sedentary were not recorded. Therefore, the data has to be cleaned and incorrect trajectory records needed to be removed. In future studies, we will incorporate the road network data and map matching methods to address such situations. Second, the comprehensiveness of OSM data varies in different cities. When analyzing the activities along with OSM data, the richness of the findings rely heavily on detailed information regarding POIs. In the future, we can combine geographic data from multiple sources to increase the coverage of POIs in cities. Third, because our focus of this project was to develop the functionality to capture multi-dimensional attributes of activities, we did not deploy our application to a larger group of participants. Instead, we only obtained a test dataset by running the app for 5 days. The application was able to capture useful information at multiple scales. We also demonstrated the captured information could be used in projects in measuring physical activities and environmental exposure. In the future, we plan to conduct a comprehensive assessment. We will recruit participants and invite them to use the app for an extended period. Along with the app, we will also use pedometers and accelerometers and self-reported activity diaries to validate the app-based step and duration measures. We also plan to apply the proposed system in empirical studies investigating issues regarding the human–environment interaction, such as crime risk modeling and food exposure analysis.


4 Example Applications

The power of APIs is that they allow data to be accessed using a common protocol but analyzed and displayed in many different ways. Several mobile and web applications that use the Macrostrat API are now publicly available, including the iOS and Android application Flyover Country and the iOS application Mancos, each developed by third parties. Here we briefly describe the Rockd mobile application developed by the Macrostrat group.

Rockd (https://rockd.org) is built using the Ionic framework and it leverages Macrostrat's geologic map data as well as lithostratigraphic nomenclature, lithologies, paleogeographic reconstructions, and more. One of the fundamental questions that Rockd aims to help users answer is, “what rock am I standing on, and where and when did it form?” Finding the answer to such a question previously required either knowledge and direct observation or searching for a scale-appropriate geological map, viewing the map, and then estimating a location on that map relative to landmarks or a GPS device's coordinates. Then, once a geological age and context was acquired from a map or other published source, a user would still typically have to locate and consult other sources for a reconstructed paleogeographic position at the time of the rock's formation.

Macrostrat's data infrastructure allows users to answer the “what am I standing on” question in real time anywhere in the world, with levels of detail that vary regionally but using a platform that continually improves. This same data infrastructure also allows users to obtain their current elevation using digital elevation models (ETOPO1 and SRTM1) instead of the elevation reported by their device's GPS chip, which is prone to large errors in vertical position (GPS-specific and device-specific uncertainty in horizontal position still occurs and will affect elevation estimates precision of the GPS-supplied latitude-longitude estimate is reported in Rockd). Additionally, by retrieving data from a web API wrapper of GPlate's (Wright et al., 2013 ) PyGPlates Python package, users are automatically given their paleoposition for any time going back to 750 Ma. Global paleogeographic reconstructions and the user's paleoposition are then shown on paloegeographic reconstructions from C. R. Scotese (Scotese, 2016 ). Reliance on Macrostrat's API (and Rockd's own API) allows the application to be continually updated without any user intervention (e.g., a new geological map added to Macrostrat will be accessible without requiring installation of a new version of the application).

In addition to providing local geological context, Rockd allows registered users to record their own field observations and to make them public on Macrostrat servers. User observations can leverage existing geological knowledge, such as stratigraphic names, lithologies, and taxonomic names that are known to occur around the observation's location. Providing this type of location-specific information can speed up the data acquisition process and improve the quality of data by reducing the need to type text. Delivering local geological context also, in principle, encourages users to focus their efforts on making observations that might supply new information or that complements or revises existing information, thereby enhancing local geological knowledge and ultimately improving rock unit descriptions. In keeping with REST principles, Rockd photos, observations and locations are assigned URLs that, when made public by a user, can be shared (e.g., https://rockd.org/checkin/1727) and commented on by other registered users, offering a mechanism to label locations with alternative interpretations and encourage a learning dialogue. User-contributed checkins (Rockd's term for a location with one or more observations) can also help streamline field work and the planning of field trips. The ability to create custom, ordered groupings of locations that can be named and identified by a single URL is forthcoming and will serve as the organized “field trip” component of Rockd.

Rockd is a mobile app that draws on Macrostrats API for data exploration and visualization purposes, but the Macrostrat data service can also be used in geoscientific applications. Figure 6 shows output from one such scientific application. In this example, unit data in either JSON or CSV format are first retrieved from the Macrostrat API using the URL above. These data are then parsed and for each time increment of interest (here 0–541 Ma) and the number of units with overlapping ages are then counted by looping over all units in the response. If the fields with the continuous-time age estimate for each unit are used (“b_age” and “t_age”), then this estimate can be a time “interval-free” summarization of rock quantity through geologic time. Other parameters, such as rock area and volume can be summarized in the same capacity, although the latter requires the user to make decisions about how to include proportional lithological abundances and the maximum and minimum thickness estimates that accompany each unit.


An effective guide to geographic information systems and remote sensing analysis using Python 3

  • Construct applications for GIS development by exploiting Python
  • This focuses on built-in Python modules and libraries compatible with the Python Packaging Index distribution system - no compiling of C libraries necessary
  • This practical, hands-on tutorial teaches you all about Geospatial analysis in Python

If you are a Python developer, researcher, or analyst who wants to perform Geospatial, modeling, and GIS analysis with Python, then this book is for you. Familarity with digital mapping and analysis using Python or another scripting language for automation or crunching data manually is appreciated.

  • Automate Geospatial analysis workflows using Python
  • Code the simplest possible GIS in 60 lines of Python
  • Mold thematic maps with Python tools
  • Get hold of the various forms that geospatial data comes in
  • Produce elevation contours using Python tools
  • Create flood inundation models
  • Apply Geospatial analysis to find out about real-time data tracking and for storm chasing

Geospatial Analysis is used in almost every field you can think of from medicine, to defense, to farming. This book will guide you gently into this exciting and complex field. It walks you through the building blocks of geospatial analysis and how to apply them to influence decision making using the latest Python software.

Learning Geospatial Analysis with Python, 2nd Edition uses the expressive and powerful Python 3 programming language to guide you through geographic information systems, remote sensing, topography, and more, while providing a framework for you to approach geospatial analysis effectively, but on your own terms. We start by giving you a little background on the field, and a survey of the techniques and technology used. We then split the field into its component specialty areas: GIS, remote sensing, elevation data, advanced modeling, and real-time data.

This book will teach you everything you need to know about, Geospatial Analysis from using a particular software package or API to using generic algorithms that can be applied. This book focuses on pure Python whenever possible to minimize compiling platform-dependent binaries, so that you don't become bogged down in just getting ready to do analysis. This book will round out your technical library through handy recipes that will give you a good understanding of a field that supplements many a modern day human endeavors.

This is a practical, hands-on tutorial that teaches you all about Geospatial analysis interactively using Python.


Playing with data

Reading & writing GIS data

Programmatic data munging

Pure Python, reads (and writes) shapefile data. That's all.

For more complicated things

GDAL/OGR: Massive library of raster & vector GIS tools.

  • (Can be) a pain in the #%! to install/config
  • Docs & features can be overwhelming
  • Chaining commands gets cumbersome
  • Native Python bindings are nasty

GDAL/OGR: command line tools

ogrinfo: get summary info on a given spatial dataset or run SQL queries on the fly - accepts any* file type

ogr2ogr: transform any* vector GIS filetype into any other type, optionally filtering by arbitrary SQL query

*Presque quelconque

Good news: We speak Python

Caveat: Many Python libs still require GDAL/OGR installations and headers. Worth it, but can be a bumpy ride the first time around.

GIS I/O + Python

(Use THIS - ne pas GDAL/OGR's vanilla API s )

Supports every format OGR supports (not just shapefiles), makes reading/munging/writing GIS data a breeze.

For Rasters.

The Fun Stuff

  • Create buffers around vector elements
  • Visualize things like convex hulls, unions, intersections, centroids.
  • Find (geometric) differences between elements

Combiner Fiona + Shapely to chain reading, converting, and analysing GIS data:


Voir la vidéo: Create Spatial Table u0026 Add Geometry Column in #PostGIS. #PG #QGIS. Urdu. Hindi. Eng. #19 (Octobre 2021).