Raster de géoréférence dans un plan non horizontal


8

Nous avons des données raster générées à partir de murs (verticaux). Nous souhaitons conserver ces données dans une base de données postgis et encoder la référence spatiale "de la manière la plus précise".

Actuellement, ils sont enregistrés en abusant d'un CRS métrique et codent la coordonnée z du mur en y et le décalage par rapport au côté gauche du mur en x. Cela donne un système de référence local qui fonctionne pour son objectif mais perd le contexte global.

Pour les données vectorielles, il est simple de donner à chaque sommet une coordonnée 3D pour le localiser dans l'espace (global). C'est ce qui doit être créé sur la base des données raster (utilisez une interface utilisateur SIG pour numériser les zones d'intérêt au-dessus de ces murs).

De plus, plusieurs murs peuvent être situés côte à côte et il devrait être possible de les visualiser dans ce contexte (cela suffit si cela ne fonctionne que s'ils ont le même azimut).

Il existe quelques approches pour résoudre ce problème:

Utilisez un CRS personnalisé dans l'espace vertical, dont l'origine est basée sur des coordonnées réelles. Cependant, où exactement cette "référence d'origine" serait stockée n'est pas encore claire.

  • Enregistrer les informations dans le CRS (est-ce possible?) - Il faudrait plusieurs CRS différents pour chaque plan de référence.
  • Utiliser une clé étrangère pour une ligne (voir les lignes rouges dans l'exemple) - Situation actuelle, informations redondantes (que faire si la longueur de la ligne ne correspond pas à la largeur du raster?)
  • Créer un polygone 3D comme plan de référence - Informations redondantes, voir ci-dessus
  • Créez un point d'origine sur la ligne qui, en combinaison avec l'azimut de la ligne, peut être le plan de référence - Des murs différents partageraient-ils le même plan de référence?

Toutes les approches semblent être en quelque sorte des «solutions de contournement» et ont leurs mises en garde.

Les deux images ci-dessous montrent une vue de dessus de la situation et une composition de plusieurs images tramées frontales. (C'est correct s'ils sont mappés sur un seul plan de référence)

Quelle est la façon la plus appropriée de stocker les images raster verticales dans la base de données sans perdre son contexte géographique dans l'espace horizontal et avec les informations d'altitude?

Plan de dessus de la situation, les lignes rouges correspondent à l'emplacement réel des rasters.

Un ensemble d'images tramées orthorectifiées, correspondant à des lignes rouges avec le même azimut.


3
quelle est encore la question?
nickves

Avez-vous pensé à stocker vos données au format NetCDF? Je n'ai pas fait grand chose dans ce domaine, mais c'est une voie possible, vous pouvez stocker vos données verticales comme dimension supplémentaire.
yanes

1
À droite, nous sommes sur un site de questions / réponses :) Question formulée. Bien que nous ayons encore toutes les possibilités ouvertes dans ce projet (c'est-à-dire que NetCDF serait une possibilité), je ne voudrais pas perdre tous les avantages introduits par une base de données.
Matthias Kuhn

Réponses:


1

douteux, c'est la réponse élégante, mais cela ressemble à quelque chose que nous avons fait - où nous avons commencé avec des coupes transversales numérisées (rasters verticaux, comme vos murs). Nous avons géoréférencé les images où le décalage du côté gauche était la coordonnée x et la hauteur de la section x était y. ces coordonnées étaient dans le même CRS que toutes nos autres données cartographiques pour la région.

polygones numérisés

Nous avons ensuite simplement numérisé les rasters et inclus un ensemble de données ponctuelles distinct pour indiquer les vrais coins de début / fin des coupes transversales.

lignes numérisées

De là, un court script peut extraire les sommets des lignes, et en utilisant les coins, nous pourrions transposer les points pour les afficher dans un espace 2D ou 3D - (note en 2D - tous les points s'empilent les uns sur les autres dans le plan vertical)

Affichage des points 3D en 2D

ou dans une visionneuse 3D -

entrez la description de l'image ici

bien que nous ne les ayons pas stockés dans une base de données, le concept devrait être le même.

maintenant, peut-être qu'il y a une énorme erreur dans notre méthode - donc je serais heureux (enfin, pas vraiment) d'entendre cela aussi. si cela m'intéresse, je pourrais partager le script kludgy que nous avons utilisé pour transposer les données.


Je pense que c'est à peu près l'approche que nous avons actuellement. Mis à part les scripts qui semblent effectivement intéressants, mais cette question concerne principalement le stockage des données.
Matthias Kuhn

dans ce cas, le CRS précédent pour la zone d'étude était en UTM. nous l'avons maintenu pour les rasters verticaux. Bien sûr, vous pouvez ajouter une exagération verticale - il suffit d'en tenir compte dans la transposition.
fluidmotion

1
Je suis sûr que je ne pense pas à cela avec suffisamment de mesures - pour `` coder la coordonnée z du mur en x et le décalage par rapport au côté gauche du mur en y '' - semble opposé à la façon dont nous l'avons stocké? pour mon esprit simple, il était facile de placer la base du raster de mur exactement là où il devrait être sur la carte - et en 2D, ce serait comme s'il était tombé à plat sur le sol. Tous dans le même CRS?
fluidmotion

non, c'est en fait une faute de frappe dans ma question :)
Matthias Kuhn

réalisé que je n'avais pas complètement répondu à votre question. Oui, tout est dans le même CRS proche de l'origine (x: proche de 0 / y, autour de l'altitude du site). Donc, pour voir les rasters au lieu de la carte, nous utilisons simplement "zoomer sur l'étendue de la couche". La bonne chose à ce sujet est que dans le compositeur d'impression une grille horizontale indiquera l'altitude.
Matthias Kuhn
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.