Le calcul de la zone QGIS diffère lorsque la transformation CRS à la volée est activée

10

Lorsque j'ouvre QGIS, ajoute la couche et calcule les zones du fichier de formes via la calculatrice de champ, j'obtiens une zone différente de celle lorsque j'ouvre QGIS et coche «Activer la transformation CRS à la volée» et calcule la zone. Ceci malgré le fait que le projet et le calque ont le même système de coordonnées (même numéro EPSG). Qu'est-ce que je fais mal?

J'ai un fichier de formes avec des calculs de zone effectués avec ArcGIS (pas moi, les données m'ont été remises et je n'ai aucune idée pour quel CRS la zone a été calculée avec ArcGIS). La couche de fichiers de formes CRS est EPSG: 21781 (Suisse). Dans QGIS, si je ne modifie pas les paramètres OTF et que je laisse le projet CRS comme EPSG: 4326 (WGS84), j'obtiens la même valeur que la valeur de la zone ArcGIS. Cependant, si je modifie l'OTF avant d'ajouter le calque à EPSG: 21781, j'obtiens des valeurs de zone différentes. Si je comprends bien, cela suggère que la zone ArcGIS a été calculée avec le CRS EPSG: 4326.

Premier workflow:

  1. ouvrir QGIS
  2. projet CRS: EPSG 4326
  3. ajouter un calque
  4. le projet CRS s'adapte automatiquement et est maintenant EPSG 21781
  5. calculer $ surface avec calculatrice de champ

Deuxième workflow:

  1. ouvrir QGIS
  2. projet CRS: EPSG 4326
  3. Activez OTF, définissez le projet CRS sur EPSG 21781
  4. ajouter un calque
  5. calculer $ surface avec calculatrice de champ

L'étape 5 des premier et deuxième workflows NE produit PAS la même zone.

qgis coordinate-system area kalakaru
la source
pouvez-vous donner un exemple du flux de travail et des outils que vous avez utilisés; Je l'ai essayé à la volée activé et désactivé dans le WGS84 et il a donné la même zone. Cela utilise $areadans la calculatrice déposée. En bref, à la volée affecte la façon dont la géométrie est affichée sans altérer de facto les données. Il est donc plus probable que l'erreur soit due au flux de travail.
dof1985
$ area calcule-t-il l'aire en fonction des couches ou du système de coordonnées du projet?
kalakaru
J'ai vérifié et il semble donner la zone dans les unités OTF; pourtant je suis sûr qu'il utilise la géométrie de la couche elle
dof1985
Cela pourrait être la racine de mon problème. J'ai un fichier de formes avec des calculs de zone effectués avec ArcGis (pas moi, les données m'ont été remises et je n'ai aucune idée pour quel CRS la zone a été calculée avec ArcGIS). La couche shapefiley CRS est EPSG: 21781 (Suisse). Si je ne modifie pas les paramètres OTF et que je laisse le projet CRS comme EPSG: 4326 (WGS84), j'obtiens la même valeur que la valeur ArcGis Area. Cependant, si je modifie l'OTF avant d'ajouter le calque à EPSG: 21781, j'obtiens des valeurs de zone différentes. Si je comprends bien, cela suggère que la zone ArcGIS a été calculée avec l'EPSG CRS: 4326.
kalakaru
autant que je sache, Arcgis peut calculer la géométrie de plusieurs façons. L'utilisation de l'expression python de la calculatrice de champ !shape.area!devrait donner l'aire en fonction des crs de la couche; que de calculer la géométrie peut fonctionner différemment. Il est donc difficile de dire exactement ce qui a été fait dans arcgis, mais si vous obtenez le même résultat, par exemple des degrés et non des mètres, cela signifie que le calcul de la surface était en effet basé sur l'ESPG: 4326.
dof1985

Réponses:

6

EDIT - Avertissement: je voudrais renvoyer les lecteurs à la discussion avec ChrisW ci-dessous. Il se pourrait que l'obtention d'une zone basée sur un OTF CRS ne soit pas un bug après tout; c'est-à-dire, au moins, en arcgis, il est également utilisé pour permettre le géotraitement de deux couches à partir de différents CRS.

Pour développer la question ci-dessus. Comme AndreJ comme suggéré et le montre - c'est probablement un bogue dans la version actuelle de qgis. Pourtant, il convient de noter que le problème n'est pas la mauvaise zone, mais que la transformation à la volée affecte de toute façon les calculs de zone.

La transformation / projection à la volée a pour but d'aligner les données de différentes sources et avec différents CRS. C'est principalement à des fins d'affichage. EG arcmap effectue automatiquement une projection à la volée dans tous les cas, une couche CRS ne correspond pas à la trame de données CRS.

Arcmap offre également la possibilité de modifier les données lors de la projection à la volée, mais note également que: ( source )

Cependant, il est important de noter que certaines opérations d'édition peuvent produire des problèmes d'alignement ou de précision inattendus, selon les systèmes de coordonnées utilisés.

Les opérations d'édition spécifiques qui peuvent entraîner des problèmes incluent la modification des formes des fonctions, l'accrochage au bord ou à la limite des fonctions, ou l'extension et le découpage des fonctions. Ces problèmes sont plus susceptibles de se produire lorsque les entités que vous modifiez sont proches du bord ou au-delà de la zone d'utilisation du système de coordonnées

C'est-à-dire: à la volée, la transformation est moins précise que de simplement projeter les données vers un CRS différent (ce qui introduit également ses propres problèmes).

Cela dit, il n'est pas surprenant que, sur la base d'une transformation à la volée, une mauvaise zone soit calculée, mais il est surprenant que le fait que la volée ait été activée affecte de quelque manière que ce soit le calcul de la géométrie, qui devrait être basé sur les données. Ainsi, peu importe si la transformation à la volée est basée sur le même CRS ou un CRS différent, le calcul de la surface doit être identique à chaque fois.

Pour être plus pratique, si votre objectif est de calculer la zone, ne l'utilisez pas à la volée. Si vous avez le mauvais CRS, projetez vos données.

dof1985
la source
Je ne suis pas sûr de QGIS, mais contrairement à ce que vous mentionnez ici, ArcGIS peut réellement faire sa Calculer la géométrie en utilisant une projection OTF ou une projection complètement différente selon la méthode (c'est-à-dire cliquer avec le bouton droit sur la colonne d'attribut et choisir Calculer la géométrie vs une -appel de calculatrice de code / champ de shape.area). Il y a parfois des choix donnés pour utiliser le CRS de 1) données / couche, 2) trame de données actuelle, 3) un CRS spécifié sans rapport avec 1 ou 2. Typiquement (encore une fois, ArcGIS) si le choix n'est pas présenté, il sera fait dans le CRS de la trame de données actuelle, quelle que soit la nature des données (d'où OTF).
Chris W
Je dois également mentionner que l'OTF n'est pas uniquement à des fins d'affichage - il n'est pas nécessaire de reprojeter un ensemble de données pour exécuter un outil de géotraitement qui utilise également un ensemble de données avec un CRS différent; La FTO s'en occupe. Il y a quelques exceptions à cette règle , lorsque les deux ensembles de données ne doivent être dans le même SIR.
Chris W
@ChrisW, si je comprends bien; certains outils de géotraitement acceptent le CRS OTF car il s'agissait du CRS de la couche. Ainsi, obtenir une zone basée sur OTF CRS n'est pas nécessairement un bug. Est-ce exact? Concernant Arcgis, supposons WGS84 comme OTF; que diriez-vous d'un appel comme:!shape.area@meters!
dof1985
C'est correct. Votre trame de données et votre première couche peuvent être WGS84, et vous pouvez ajouter une deuxième couche qui est NAD83. La deuxième couche est projetée OTF, et vous pouvez exécuter n'importe quel outil normal comme Intersect ou Union dessus et l'opération a lieu dans WGS84. Obtenir la zone n'est certainement pas un bug. J'ai un client qui veut des données en NAD83, mais les informations nécessitent des unités en acres et que je travaille dans un CRS projeté pour entrer des informations. Je modifie généralement la projection de la trame de données, la zone de calcul, puis la rétablis. Je ne sais pas comment cet appel serait géré car je pense que la conversion d'unité est distincte du calcul.
Chris W
6

Je peux confirmer que cela semble être un bug.

Créez un fichier csv avec le contenu suivant:

E N
600000 200000
700000 200000
700000 300000
600000 300000

Importez-le sous forme de texte délimité avec EPSG: 21781, activez l'accrochage et dessinez un fichier de formes polygonales sur les quatre points.

Sans OTF, le résultat $area/1000000.0est de 10000 m² (ce qui est évidemment correct).

Mise FTO sur , et en sélectionnant le même EPSG: 21781, vous 9988,2338 m².

Le choix d'un CRS différent, comme l'EPSG: 4326, délivre 9990,5339 m², car le calcul se fait sur un ellipsoïde différent (WGS84 au lieu de bessel).

Vector --> Geometry Tools --> Export/Add Geometry Columns semble fournir des valeurs correctes.

Le bug a déjà quelques tickets: https://issues.qgis.org/issues/10966 et https://issues.qgis.org/issues/12473

AndreJ
la source