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!).