Ma société utilise le type de données geometry( the_geom) pour stocker les données géospatiales.

Je me suis récemment familiarisé avec le concept de type de données geography( the_geog) qui, tel que je le comprends, enregistre le SRIDavec la géométrie.

Quelles sont les différences entre geographyet geometry, et y a-t-il un avantage à utiliser l'une d'elles dans les grandes bases de données?

Les entités géographiques sont toujours stockées dans WGS84 avant PostGIS 2.2; depuis lors, tout système de référence spatiale basé sur lon / lat peut être utilisé. Les mesures basées sur les entités géographiques seront exprimées en mètres plutôt qu'en unités CRS et PostGIS utilisera des calculs géodésiques au lieu de géométrie plane.

Non, toutes les fonctions ne prennent pas en charge la géométrie, mais vous pouvez choisir entre géométrie et géographie. Pour la liste des fonctions en cours, voir: https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions

Je ne pense pas qu'il soit possible de recommander la géographie ou la géométrie pour des bases de données volumineuses. Cela dépend de ce que vous faites avec vos données. Les calculs sur la sphère étant plus compliqués, je m'attendrais à ce que les analyses soient plus lentes pour les entités géographiques. Vous devez également transformer toutes vos données en WGS84 pour utiliser la géographie.

Si vous faites beaucoup de mesures et que vous devez par exemple comparer la taille de grands polygones, il serait logique d'utiliser la géographie plutôt que la géométrie.

J'ai trouvé ce qui suit utile: http://postgis.net/workshops/postgis-intro/geography.html

Le sujet est également traité dans "PostGIS in Action" (ISBN: 9781935182269).

J'utilise mes "règles empiriques" intuitives ... C'est utile pour une décision rapide,

• À propos de votre BASE DE DONNÉES : si les caractéristiques et / ou l’analyse spatiale sont à l’échelle continentale et ont besoin de précision (applications sérieuses), utilisez la géographie . Sinon, utilisez la géométrie: lorsque toutes les bases de données se rapportent à la même région ( à l'échelle d'une ville ), ou que vous n'avez pas besoin de précision, etc., vous avez uniquement besoin de géométrie.
  Voir la règle similaire à la lecture suggérée de @underdark .

• Concernant vos besoins en termes de PERFORMANCE / PRÉCISION BALANCE: la géométrie est plus rapide; Si vous avez besoin de performances et que vous pensez utiliser la géographie, faites d’abord vos repères.

Concepts clés

Sur cette page, nous voyons quelques mots clés et l'accent mis sur certains concepts: précision , performance et quelque chose comme flexibilité / commodité d'utilisation .

Comme d'autres l'ont rappelé, la différence, pour le stockage et les calculs, réside dans l'utilisation de sphère en géographie et de plan en géométrie:

• la sphère (géographie) est meilleure, plus précise. Voir l'exemple Los Angeles / Paris .
• évolution de la géographie: comme @DavidF le dit, "le type de géographie a été ajouté plus récemment, donc moins de fonctions sont supportées / implémentées".

Peut-être qu'en 2020 toutes les bases de données SIG seront configurées sur le même standard SRID / EPSG (équivalent du code actuel 4326, pour WGS84). Aujourd'hui, la géographie n'est pas un choix par défaut en raison de ses performances et de ses limitations fonctionnelles.

Discussion

À mon avis, il s’agit de "meilleures pratiques" et non d’un problème technique / théorique profond.

Précision

Après avoir estimé l’erreur sur vos données, effectuez vos tests et comparez les résultats: les gains de précision avec la géographie sont supérieurs à l’erreur de données? La fonction ST_Distance (avec les agrégateurs MAX et AVG ) est la référence principale dans ce type d’expérience.

Performance

Exemples de points de repère dans une zone urbaine d’environ 100 km2 (diamètre environ 11 km), tous stockés sous forme de géométrie, dans un système de coordonnées plan UTM. REMARQUE: en commençant par la conversion géométrique / géographie fréquemment utilisée - fréquemment parce que certaines fonctions n'existent pas et que d'autres, telles que ST_Buffer et ST_Intersection, effectuent la conversion en interne.

Banc n ° 1: un tableau avec environ 87 000 polygones représentant des lots urbains, chacun avec poly avec (avg) ~ 13 points,

 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS 
        SELECT gid, the_geom FROM urbanlots; ROLLBACK;
 -- time 2080 ms   ~ 2.0 s
 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS 
        SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog 
        FROM urbanlots; ROLLBACK;
 -- time 12374 ms ~ 12.4 s  ~ 6 * geometry.

donc, geography_time = 6 * geometry_time.

Banc n ° 2: une table avec environ 3 500 polygones représentant des blocs urbains, chacun contenant un poly avec (moyenne) ~ 50 points: 0,6 vs 2,7, geography_time = 4.5 * geometry_time.

Banc n ° 3: ~ 10000 lignes représentant les rues urbaines, chacune avec ~ 5 points. ~ 0.87s vs ~ 0.36s, geography_time = 2.4 * geometry_time.

Retour à la table n ° 2, créer les tables et faire les requêtes,

 EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom) 
         FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
 -- time 182 ms   ~ 0.2 s
 EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog) 
         FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
 -- time 58657 ms  ~ 59 s  ~  300*geometry
 -- curioselly for only distances, geography=4*geometry

Conclusion: pour les petites tâches et bien conscientes, les temps convergent vers le "même temps acceptable", mais pour les grosses tâches, il y a lieu d'évaluer les performances.

Flexibilité / Produit

Sur les repères, je fais une tâche au jour le jour, vérifiant le nombre de points (par ST_NPoints) ... C'est un exemple d'opération qui n'existe pas pour la géographie, les besoins exprimés. La "distribution géographie / géométrie" est une tâche agaçante pour les programmeurs, les maîtres, etc.

Lors de la réutilisation de bibliothèques de fonctions SQL et PL / pgSQL, la géographie nécessite des adaptations. Et si vous souhaitez optimiser le code ou éviter les problèmes de précision avec de nombreuses conversions intermédiaires, l'absence d'un ensemble complet de fonctions intégrées, avec la géographie, constitue un autre problème. Programme pour la géographie, n'est pas une tâche facile.

Process-only, échange de données, etc.

Pour les demandes inhabituelles, sans utilisateur intensif comme Mapserver, lorsque votre seul travail (PostGIS) consiste à traiter les données d'entrée et à renvoyer à tout moment (en heures ou en jours) les données traitées, la règle de base est "utilisez la géographie si vous sont à l'aise! " (voir "Flexibilité / Produit" ci-dessus). Sinon, vérifiez les règles habituelles.
REMARQUE: bien sûr, si votre tâche (inhabituelle) consiste uniquement à afficher les données de PostGIS vers Mapserver, il n'est pas nécessaire de recourir à un processus pour conserver la même configuration (géométrie ou géographie) de vos données d'entrée.

Je pense que la centralisation des données est une autre tâche pour laquelle la géographie est préférable: dans un contexte où la diversité des formats d'entrée et des systèmes de référence est habituelle, l'utilisation d'une norme, telle que celle imposée par la géographie, est bénéfique ... La convention sur la configuration est un bon principe lorsque la centralisation et l’échange de données sont au cœur des préoccupations de l’entreprise (voir Google Maps!).

Je pense que la différence la plus significative est que, avec le type géographique, les calculs sont effectués sur une sphère représentant la Terre, par opposition à la surface plane utilisée dans les calculs effectués sur des entités de type géométrique.

Les documents sont plutôt bons: http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography

Le type géographique a été ajouté plus récemment, de sorte que moins de fonctions sont supportées / implémentées.

Peut-être trouvez-vous cette fonctionnalité - et sa réponse - inutile, mais l'un des avantages du travail avec les géométries est que vous pouvez travailler sans aucune référence spatiale (c'est-à-dire que SRID est défini sur -1).

Actuellement, je travaille dans une application qui filtre les données LiDAR aéroportées. Parmi ses sources de données, il y a une base de données PostGIS, qui fournit une indexation spatiale de première classe ( RTree over GiST ) et gère sans problème un volume de données important. Cette application ne nécessitant ni manipulation ni analyse de caractéristiques géographiques, aucun SRID n’est nécessaire, ce qui évite les frais généraux qu’elle peut entraîner.