실시간 CRS 변환이 활성화 된 경우 QGIS 영역 계산이 다릅니다


10

QGIS를 열고 레이어를 추가하고 필드 계산기를 통해 shapefile의 영역을 계산할 때 QGIS를 열 때와 다른 영역이 표시되고 "즉석에서 CRS 변환 사용"을 확인하고 영역을 계산합니다. 프로젝트와 레이어에 동일한 좌표계 (동일한 EPSG 번호)가 있는지 확인해야합니다. 내가 무엇을 잘못하고 있지?

ArcGIS로 만든 면적 계산이있는 shapefile이 있습니다 (나가 아닙니다. 데이터가 나에게 전달되었으며 ArcGIS로 면적이 계산 된 CRS에 대한 실마리는 없습니다). 쉐이프 파일 레이어 CRS는 EPSG : 21781 (스위스)입니다. QGIS에서 OTF 설정을 변경하지 않고 프로젝트 CRS를 EPSG : 4326 (WGS84)으로두면 ArcGIS 영역 값과 동일한 값을 얻습니다. 그러나 EPSG에 레이어를 추가하기 전에 OTF를 변경하면 : 21781 다른 영역 값을 얻습니다. 내가 이해하는 것처럼 ArcGIS Area는 CRS EPSG : 4326으로 ​​계산되었습니다.

첫 번째 워크 플로우 :

  1. QGIS를여십시오
  2. 프로젝트 CRS : EPSG 4326
  3. 레이어 추가
  4. 프로젝트 CRS가 자동으로 조정되어 EPSG 21781 임
  5. 필드 계산기로 $ area 계산

두 번째 워크 플로우 :

  1. QGIS를여십시오
  2. 프로젝트 CRS : EPSG 4326
  3. OTF를 켜고 프로젝트 CRS를 EPSG 21781로 설정
  4. 레이어 추가
  5. 필드 계산기로 $ area 계산

첫 번째 및 두 번째 워크 플로우의 5 단계는 동일한 영역을 생성하지 않습니다.


사용한 워크 플로 및 도구의 예를 제공 할 수 있습니까? WGS84에서 즉시 사용 및 사용 중지로 시도했지만 동일한 영역을 제공했습니다. 그것은 $area출원 된 계산기에서 사용 하고 있습니다. 즉, 온더 플라이는 데이터를 변경하지 않고 형상이 표시되는 방식에 영향을줍니다. 따라서 오류는 워크 플로 때문일 가능성이 큽니다.
dof1985

$ area는 레이어 또는 프로젝트 좌표계를 기준으로 면적을 계산합니까?
kalakaru

확인한 결과 OTF 단위로 영역을 제공하는 것 같습니다. 그러나 레이어 자체의 지오메트리를 사용한다고 확신합니다
dof1985

그것은 내 문제의 근원 일 수 있습니다. ArcGis로 만든 면적 계산이있는 shapefile이 있습니다 (나가 아닙니다. 데이터가 나에게 전달되었으며 ArcGIS로 면적이 계산 된 CRS에 대한 실마리는 없습니다). 형상 파일 층 CRS는 EPSG : 21781 (스위스)이다. OTF 설정을 변경하지 않고 프로젝트 CRS를 EPSG : 4326 (WGS84)로두면 ArcGis Area 값과 동일한 값을 얻습니다. 그러나 EPSG에 레이어를 추가하기 전에 OTF를 변경하면 : 21781 다른 영역 값을 얻습니다. 내가 이해하는 것은 ArcGIS Area가 CRS EPSG : 4326으로 ​​계산되었다는 것을 암시합니다.
kalakaru

내가 아는 한 Arcgis는 여러 가지 방법으로 형상을 계산할 수 있습니다. 필드 계산기의 파이썬 표현식 !shape.area!을 사용하면 레이어 crs에 따라 영역을 제공해야합니다. 형상 계산보다 다르게 작동 할 수 있습니다. 따라서 arcgis에서 수행 된 작업을 정확하게 파악하기는 어렵지만 미터가 아닌 도와 같은 동일한 결과를 얻는 경우 영역 계산이 실제로 ESPG : 4326을 기반으로한다는 것을 의미합니다.
dof1985

답변:


6

편집-면책 조항 : 독자들에게 아래 ChrisW와의 토론을 언급하고 싶습니다. OTF CRS를 기반으로 한 영역을 얻는 것이 결국 버그가 아닐 수도 있습니다. 즉, 적어도 arcgis에서는 다른 CRS의 두 레이어를 지오 프로세싱하는 데에도 사용됩니다.

위의 문제를 자세히 설명합니다. AndreJ가 제안하고 보여 주듯이-이것은 아마도 qgis의 현재 버전의 버그 일 것입니다. 그러나 문제는 잘못된 영역이 아니라 실시간 계산이 영역 계산에 영향을 미칩니다.

온더 플라이 변환 / 투영의 목적은 다른 소스와 다른 CRS의 데이터를 정렬하는 것입니다. 그것은 주로 표시 목적입니다. EG 아크 맵은 레이어 CRS가 데이터 프레임 CRS와 일치하지 않는 경우 자동으로 즉시 투영을 수행합니다.

(: ArcMap의도에 - 더 - 플라이 예상하면서 편집 데이터에 대한 가능성을 제공뿐만 아니라 노트 그 소스 )

그러나 사용중인 좌표계에 따라 특정 편집 작업으로 인해 예기치 않은 정렬 또는 정확도 문제가 발생할 수 있습니다.

문제를 일으킬 수있는 특정 편집 작업에는 형상의 모양 변경, 형상의 가장자리 또는 경계에 스냅하거나 형상 확장 및 트리밍이 포함됩니다. 이러한 문제는 편집중인 형상이 좌표계의 모서리에 가까워 지거나 사용 영역을 벗어날 때 발생할 수 있습니다.

즉, 즉석 변환은 데이터를 다른 CRS에 투영하는 것보다 덜 정확합니다 (자체적 인 문제가 발생 함).

온더 플라이 변환을 기반으로 잘못된 영역을 계산한다는 것은 놀라운 일이 아니지만 온더 플라이가 활성화되었다는 사실이 지오메트리 계산에 어떤 식 으로든 영향을 미친다는 것은 놀라운 일입니다. 데이터를 기반으로합니다. 따라서 온더 플라이 변환이 동일하거나 다른 CRS를 기반으로하는지 여부는 중요하지 않으며, 매번 영역 계산이 동일해야합니다.

더 실용적으로, 목표가 면적을 계산하는 것이라면 즉석에서 사용하지 마십시오. 잘못된 CRS가있는 경우 데이터를 투영하십시오.


QGIS에 대해서는 잘 모르겠지만 여기서 언급 한 것과는 달리 ArcGIS는 실제로 방법에 따라 OTF 투영법 또는 완전히 다른 투영법을 사용하여 기하학 계산을 수행 할 수 있습니다 (예 : 속성 열을 마우스 오른쪽 버튼으로 클릭하고 기하학 대 계산을 선택하십시오) 모양 / 영역의 코드 / 필드 계산기 호출). 때로는 1) 데이터 / 레이어, 2) 현재 데이터 프레임, 3) 1 또는 2와 관련이없는 특정 CRS의 CRS를 사용하도록 선택하는 경우가 있습니다. 일반적으로 (다시, ArcGIS) 데이터가 무엇이든 (따라서 OTF) 현재 데이터 프레임의 CRS
Chris W

또한 OTF는 단지 표시 목적만을위한 것이 아니라 다른 CRS를 가진 데이터 세트를 사용하는 지오 프로세싱 도구를 실행하기 위해 데이터 세트를 재 투영 할 필요가 없습니다. OTF가 처리합니다. 두 데이터 세트 모두 동일한 CRS에 있어야하는 경우에는 예외 가 있습니다.
Chris W

@ChrisW, 올바르게 이해하면; 일부 지오 프로세싱 도구는 OTF CRS를 계층의 CRS로 받아들입니다. 따라서 OTF CRS를 기반으로 영역을 얻는 것이 반드시 버그는 아닙니다. 그 맞습니까? Arcgis와 관련하여 WGS84를 OTF로 가정합니다. 다음과 같은 전화는 !shape.area@meters!
어떻습니까

맞습니다. 데이터 프레임과 첫 번째 레이어는 WGS84 일 수 있으며 NAD83 인 두 번째 레이어를 추가 할 수 있습니다. 두 번째 레이어는 OTF로 투영되며 Intersect 또는 Union과 같은 일반 도구를 실행할 수 있으며 WGS84에서 작업이 수행됩니다. 영역을 얻는 것은 분명히 버그가 아닙니다. NAD83의 데이터를 원하는 클라이언트가 있지만 정보에 에이커 단위가 필요하며 정보를 입력하기 위해 투영 된 CRS에서 작업하고 있습니다. 일반적으로 데이터 프레임 투영, 계산 영역을 변경 한 다음 다시 전환합니다. 단위 변환이 계산과 분리되어 있다고 생각하기 때문에 해당 호출이 어떻게 처리되는지 확실하지 않습니다.
Chris W

6

버그 인 것 같습니다.

다음 내용으로 csv 파일을 작성하십시오.

E N
600000 200000
700000 200000
700000 300000
600000 300000

EPSG : 21781을 사용하여 구분 된 텍스트로 가져오고 스냅을 활성화하고 4 개의 점에 다각형 모양 파일을 그립니다.

OTF가 없으면 결과 $area/1000000.0는 10000 m²입니다 ( 정확히 맞음 ).

OTF 켜고 동일한 EPSG : 21781을 선택하면 9988.2338m²가됩니다.

EPSG : 4326과 같은 다른 CRS를 선택하면 계산은 다른 타원체 (베셀 대신 WGS84)에서 수행되므로 9990.5339m²를 제공합니다.

Vector --> Geometry Tools --> Export/Add Geometry Columns 올바른 값을 제공하는 것 같습니다.

이 버그에는 이미 https://issues.qgis.org/issues/10966https://issues.qgis.org/issues/12473 티켓이 있습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.