Shapefile 기술 사양의 "기호"

32

shapefile 파싱 라이브러리를 작성하고 있으며 사양 에서 몇 가지 설계 결정 을 내 렸으며 즉시 이해할 수 없습니다. 여기에 오래된 ESRI 개발자가 있는데 왜 이런 것들이 그런지 말해 줄 수 있기를 바랍니다.

기본 레코드 파일 (.shp)은 혼합 엔디안 입니다. 특히 헤더 부분에는 빅 엔디안 바이트 순서가 있지만 레코드는 모두 리틀 엔디안입니다. 나는 일반적으로 바이트와 비트보다 높은 수준에서 작업하지만 엔디안에 대해 지금까지 읽은 모든 것이 이것을 비정상으로 표시합니다. 파일이 균일 엔디안으로 지정되지 않은 이유는 무엇입니까?
다른 길이 및 위치 필드뿐만 아니라 "파일 길이"필드는 더 표준적인 (제 제한된 관점에서) 8 비트 위치 지정 대신 16 비트 단어로 기록됩니다. 이 결정에 어떻게 도달 했습니까?

Stack Overflow에 비슷한 질문 을 게시 했지만 응답이 없습니다. 이것이 다른 사람들에게 너무 주제가 아닌 것 같으면 그것을 닫을 수 있습니다.

shapefile

— 큰 개자리
소스

4

GeospatialPython.com의 Joel Lawhead 는 한동안 쉐이프 파일 미스테리를 해결하기 위해 노력해 왔습니다.

— 채드 쿠퍼

정확히 관련이 없지만 깔끔합니다! 나는 그것을 이해하기를 바랍니다.

— canisrufus

28

쉐이프 파일의 개발은 플랫폼 독립적으로 특별히 설계된 ArcView의 개발과 동시에 이루어졌습니다. (실제로 이는 실패로 판명되었습니다. "Neuron Data"라는 플랫폼 독립적 GUI에서 개발 된 인터페이스를 사용함으로써 많은 Windows 기능을 이용할 수 없었습니다. 결국 모든 시스템 중 최악의 상황을 반영하게되었습니다. shapefile 스펙은 처음부터 이상했지만,이 디자인 프레임 워크 내에서 반복되는 의미를 가지게되었습니다. shapefile은 많은 플랫폼 용으로 만들어 졌기 때문에, 스펙은 그중 하나를 선호해서는 안되므로 동일하게 모호해야합니다. 모든 설득의 프로그래머에게.

두 번째 질문은 사실이 아닌 가정에 근거한 것으로 보입니다. 예를 들어, "파일 길이"필드는 기본 헤더의 바이트 오프셋 24에 표시되며 최대 2 ^ 31-의 길이를 나타 내기 위해 반드시 부호가있는 4 바이트 (32 비트) 정수입니다. 1. 4 바이트 "파일 코드"와 나중에 사용하기 위해 예약 된 5 바이트 이상의 4 바이트 필드가 앞에옵니다. 이러한 공간을 예약 할 때는 물론 필드를 합리적으로 최대한 크게 만들고 싶습니다. 최대 유연성을 유지하기 위해 32 비트였습니다. 단어 경계에서 파일의 숫자 필드를 정렬하는 것도 도움이됩니다.

— 우버
소스

2

:) 정확히 내가 찾던 것. "파일 길이"필드가 "16 비트 단어로 기록됨"이라고 말하면 32 비트 정수 값이 파일 길이를 16 비트 단어로 기록한다는 것입니다. (사양에서 : "파일 길이 값은 16 비트 단어로 된 파일의 전체 길이입니다"). 바이트 길이 2 * 2 ^ 31-1을 나타낼 수있는 것으로 보입니다. 약 4GB입니다. .shx 파일의 값도 마찬가지입니다. 최대 2 * 2 ^ 31-1 바이트의 파일 길이를 지원할 수 있어야합니다. 내가 무엇을 놓치고 있습니까?

— canisrufus

좋은 지적입니다. 실제로 디자인은 4 바이트 단어 로 파일 길이와 오프셋 (.shx 파일의 포인터)을 쉽게 만들 수 있었으므로 .shp 파일의 가능한 크기를 4 * (2 ^ 31-1)로 늘릴 수 있었습니다. (약 80 억 바이트). 나는 그들이 2 바이트 단어를 선택한 이유를 아무 생각이 없으며, 심지어 왜 그들이 일관되게 사용하십시오 서명 부호없는 정수는 모두 더 적합하고 저장 용량을 두 배를 제공 정수.

— whuber

1

16 비트 이상한 int점이 당시 네이티브 가 16 비트였던 16 비트 컴퓨터와 관련이 있는지 궁금합니다 .

— Mike T

항상 가능합니다, @Mike. 그러나 80286 PC (1984 년경)조차도 기본적으로 32 비트 정수를 지원했으며 레지스터 쌍을 사용하여 산술을 수행했습니다.

— whuber

5

Esri 동료는 엔디안의 혼합이 의도적 이었다는 것을 기억한다고 말합니다. '플랫폼 간 문제로 인해 개발자가 직접 처리하게 할 것'이라는 내용이 있습니다. 그러나 물론 이것은 모두 묵시입니다.

— mkennedy 2016 년

10

거기에있는 누군가가이 답을 더 많이 알고 있지만 말을하지 않습니다.

문서화되지 않은 sbn 및 sbx 파일을 해독하기 위해 함께 노력한 팀은 동시에 유사하지만 더 기괴한 더 많은 이상한 점을 발견했습니다.

대부분의 shapefile 구조는 논리적이고 매우 효율적이므로 ESRI 개발자는 생각을 통해 생각합니다. 마치 하나의 미치광이가있는 많은 똑똑한 개발자가있는 것과 같습니다.

다른 게시물에서 제안한 바와 같이, 아마도 우리에게 낯선 기계 또는 언어 요구 사항의 결과 일 것입니다.

나는 항상 16 비트 단어가 공간을 절약하는 쉬운 방법이라고 생각했다. 파일을 처리 할 때 16 비트 워드 값을 메모리에 저장해야합니다. 공간을 절약하기 위해 값을 계산하는 전략은 오늘날에도 이진 형식으로 일반적입니다. 그러나 Mike의 기본 int 제안도 마찬가지로 가능합니다.

엔디안 충돌은 이상합니다. 내가 본 좋은 답변은 없습니다.

dbf 형식은 1960 년대에 시작된 dbase III 형식에서 추출되었습니다. 그 이후로 널리 사용되어 왔으며 foxpro 및 xbase를 포함한 다른 이름으로 찾을 수 있습니다.

shapefile 형식의 결함, 이상한 점 및 제한 사항에도 불구하고 GIS 영역 내에서 고집스럽게 지속됩니다. 그것을 대체하려는 다른 모든 시도는 단순한 벡터 저장이나 독점적 인 소유로 너무 부풀어졌습니다. ESRI조차도 shapefile은 초보자를 ArcINFO, 적용 범위 및 지리 데이터베이스로 이동시키는 장난감이 될 것이라고 생각했습니다. 인터넷은 아마도 이륙 형식과 많은 관련이있을 것입니다.

나는 pyshp를 많이 배웠습니다. 파서를 작성하는 것은 형식을 배우는 환상적인 방법입니다.

— GeospatialPython.com
소스

흠. 좋은 대답입니다. 16 비트 단어를 사용하여 공간을 절약하는 방법을 이해하지 못합니다. 내 목적 (자바 스크립트에서 ArrayBufferViews 빌드)을 위해서는 올바른 오프셋을 얻기 위해 2를 곱해야합니다. 추가 사이클을 사용하지 않아도됩니다. 당신은 정교하겠습니까?

— canisrufus

1

예-부호있는 정수를 사용했기 때문에 그 값의 상단은 32,767이므로 4 대신 2 바이트로 더 큰 숫자를 저장할 수 있습니다. 내가 말한대로 16 비트 단어에 할당 된 값은 결국 유지하는 값입니다 읽기 및 쓰기 작업을 위해 shapefile로 작업 할 때 RAM 복식 공간을 절약하기위한 계획 (다른 바이너리 형식으로 보았습니다)은 항상 추악하고 복잡합니다. 그래서 그들은 데이터 크기 값에 대한 간단한 체계를 고수했습니다.

— GeospatialPython.com

또한-나는 shx 파일에서 처음에 저를 발견했습니다. SHX 파일에는 256x256 정수 그리드에 매핑 된 피처에 대한 경계 상자가 있습니다. 이 기술은 인덱싱에서는 일반적이지만 그다지 작은 그리드에서는 그렇지 않습니다. 좌표를 정수 대신 1 바이트 문자로 저장합니다. 그리드가 256x256에 불과한 이유입니다. 이제는 1990 년대에도 기억에 얽매이지 않습니다! 물론 인덱스를 사용한 암시 적 부품 그룹화와 같은 다른 많은 효율성도 있습니다. 당신이 옳습니다-이러한 기술은 프로그래머에게 더 많은 부담을줍니다. 따라서 메모리 사용이 우선 순위였습니다.

— GeospatialPython.com

1

야, 네 글을 읽었 어 당신은 그 일에 대한 주님의 선한 일을하고 있습니다.;) 나는 당신의 최종 분석을 간절히 기다리고 있습니다. 16 비트 문제와 관련하여 귀하의 요점이 확실하지 않습니다. 1. SHP 및 SHX 파일에는 내가 잘못 생각하지 않는 한 16 비트 필드가 없습니다. 2. 8 비트 값 대신 16 비트 값을 나타내는 것은 설명 할 수없는 int (2 ^ 16)를 사용하여 간단히 달성 할 수있는 설명 가능한 길이 (2 * 2 ^ 15)의 두 배입니다. 궁극적으로 공간을 절약하지 못합니다.

— canisrufus

"메모리 사용"을 언급 할 때 RAM인지 디스크인지는 알기가 어렵습니다. 90 년대 초반에는 2GB 드라이브와 16-32MB RAM이 매우 고급 스러웠습니다. 파일 공간 (또는 네트워크 대역폭)을 절약하는 것이 여전히 중요합니다. 책임있는 소프트웨어 엔지니어는 미래의 시공간 트레이드 오프 고객이 자신의 선택에 미치는 영향을 신중하게 생각하고 싶을 것입니다. 선택의 여지가 명백하고, 비참하게 비효율적이지 않다면, 후손으로 나는 의심의 이익을 줄 것이다.

— whuber

5

이것은 내 취향이다.

쉐이프 파일 형식은 FORTRAN / PR1ME의 기원을 가진 역사를 가진 ARC / INFO에서 발전했을 가능성이 높습니다. 모든 ARC / INFO 형식에는이 100 바이트 헤더와 파일 코드 및 파일 길이 (예 : 적용 범위, TIN)의 빅 엔디안이 있습니다.

ArcView 1 용 Shapefile을 만들었을 때 ESRI는 Microsoft Windows 시장에 진출하는 데 중점을 두 었으며 나머지 Shapefile 형식은 PC의 작은 엔디안이되는 데 중점을 둡니다.

엔디안 사이의 끊임없는 전환은 아마도 플랫폼에 침입 할 때의 이점을 기대하면서 레거시 원점을 지원해야 할 필요성 일 것입니다.

— 스티븐 콴
소스

그럴듯하게 들린다. 통찰력에 감사드립니다!

— whuber

이것은 엔디안에 대한 내가 가장 좋아하는 추측입니다. 이제 우리가 필요로하는 것은 Dangermond가 "ESRI Tell All, Technical Edition"을 출판하여 귀하가 옳은지를 확인하는 것입니다!

— canisrufus

2

shapefile 형식이 ARC / INFO 형식에서 발전한 경우 v7보다 상당히 빠릅니다. 1994 년 ESRI에서 시작했을 때 AV2가 이미 종료되었으며 ARC / INFO 7의 개발 작업이 진행 중입니다.

— mkennedy

좋은 지적이야, 멜리 타 일부 형식 선택에는 궁극적으로 포트란 원점이있을 수있는이 응답의 핵심은 여전히 원래의 Arc 및 Info 응용 프로그램으로 거슬러 올라갑니다.

— whuber

@mkennedy에게 감사합니다. v7에 대한 참조를 제거했습니다. 나는 원래 ARC / INFO 사용자 매뉴얼 (v3 .. v6 시대)에 FORTRAN 코드에서 가져온 것으로 생각되는 헤더를 가지고 있었던 시절을 아직도 기억합니다.

— Stephen Quan

4

필자는 엔디안 분할이 한 팀을 썬 워크 스테이션에, 다른 팀을 PC에두고 개발 프로세스가 끝날 때까지 회의를하지 않기 때문에 발생했다고 가정했습니다.

실제로 무슨 일이 있었는지 알고 싶습니다.

— 이안 터턴
소스

3

ESRI는 그보다 약간 더 조정 된 것 같습니다. 실제로, 소프트웨어가 디자인에 너무 많은 위원회 참여가있는 것처럼 보이는 경향이 있습니다 .

— whuber

0

나는 어딘가에 dbf / foxpro 출처에 대해 들었다고 생각합니다.
그게 내가 꿈꿔 왔던 이상한 꿈이었을 것입니다.

— 브래드 네섬
소스

5

여기서 문제가되는 .shp 및 .shx 부분은 거의 20 년 전에 존재했던 .dbf 형식과 완전히 독립적으로 설계되었습니다.

— whuber

0

약 20 년 전에 셰이프 파일이 도입 된 것을 이해해야합니다. 그 당시 무수히 불일치하고 잘못 디자인 된 파일 형식이 있었으므로 셰이프 파일도 예외는 아닙니다. shapefile 파서를 직접 작성했으며 shapefile (.SHP) 자체와 비교하여 DBF 형식을 구문 분석하는 데 더 많은 문제가 있다고 말해야합니다.

— Igor Brejc
소스