Vous n'êtes pas identifié(e).
Je fais une étude sur la migration d'un projet qui comporte des données géoréférencées.
Système référentiel utilisé est le 8307.
Les données stockées sont des traces au sol allant d'un pôle à un autre. Ces données couvrent le globe.
Les seules opérations réalisées sur ces données sont des opérations de type topologique ( par ex : recherche des données à partir d'une emprise .
Nous avons besoin de toutes les opérations possibles comme st_equal, st_disjoint, st_intersects, st_overlaps, ...
Quel type postGIS je peux utiliser et comment ?
- Peut-on travailler avec des types « geometry » ?
- Peut-on travailler avec des types « geometry » et utiliser les projections ? et comment ?
- Peut-on travailler avec des types « geography » et utiliser des transformations ponctuelles au moment des recherches ? et ce sans dégrader les performances ?
Merci pour vos réponses.
Hors ligne
Le 8307 c'est bien le SRID de WGS84 ? (pas trouvé de trace dans spatial_ref_sys.sql de cet id, juste dans une doc Oracle). Je vais partir de cette hypothèse pour la suite.
- Peut-on travailler avec des types « geometry » ?
Oui, mais en les reprojetant bien sûr, ce qui risque donc d'être compliqué si les traces s'étendent sur toute la planète. Vous avez toujours les SRID WGS84 UTM (les SRID 32601 et suivants) qui permettent de faire des projections locales par tranche de 6 degrés sur le globe, pour avoir des données «pas trop absurdes» en termes de projection.
- Peut-on travailler avec des types « geometry » et utiliser les projections ? et comment ?
Avec la fonction ST_Transform. Par exemple, si votre géométrie est the_geom, et le SRID cible 3395:
ST_Transform(the_geom,3395)
- Peut-on travailler avec des types « geography » et utiliser des transformations ponctuelles au moment des recherches ? et ce sans dégrader les performances ?
Le type geography est stocké en coordonnées WGS84. Il se reprojette comme une geométrie au besoin… pour un certain nombre des fonctions, ça ne sera pas forcément la peine de reprojeter. Mais les opérations sur un type geography sont plus lentes que sur un type geometry. Et reprojeter un type geography en geometry à la volée a aussi un coût.
Pour savoir ce qui est supporté en Geography par rapport à Geometry:
http://postgis.refractions.net/document … tionMatrix
Et en 2.0 (version de dev):
http://postgis.refractions.net/document … tionMatrix
Sinon, je vous recommande la lecture de 'PostGIS in action' : http://www.manning.com/obe/ (en anglais…), parfait pour commencer sur le sujet.
Marc.
Hors ligne
Merci pour vos réponses.
Le système référentiel 8307 est une définition OGC qui est identique au référentiel 4326 ( qui lui provient de EPSG )
Pourrait-on choisir la solution suivante :
Au vu des opérations effectuées sur ces données géoréférencées qui ne sont que des opérations d’ordre topologique ( il n’y a pas de calcul de distance, de surface ) est-il possible d’utiliser le type « geometry » tout en gardant le système référentiel EPSG:4326 ?
Hors ligne
Ça risque de ne pas marcher pour tout ce qui est 'bords' de la projection (+ et - 180° de latitude, et près des pôles). Pour le reste, je ne sais pas si ça va marcher, l'arc sur le sphéroïde et la droite projetée en WGS84 sont très différents.
Marc.
Hors ligne
La migration de telles données semble quasi impossible
Hors ligne
Difficile de vous répondre avec les informations disponibles (et je ne connais pas très bien postgis). Vos traces, en termes de taille, c'est plutôt des courants océaniques, ou bien des enregistrements de randonnées pédestres ? Le second cas est plus facile à projeter en geometry, le premier est assez peu compatible avec des geometry.
Marc.
Hors ligne
