“ Oddities” ในข้อมูลจำเพาะทางเทคนิคของ Shapefile

32

ฉันได้เขียนห้องสมุดการแยกวิเคราะห์ไฟล์ shapefile และได้พบกับการตัดสินใจการออกแบบสองอย่างในสเปคที่ฉันไม่เข้าใจในทันที ฉันหวังว่าจะมีนักพัฒนาซอฟต์แวร์ ESRI เก่า ๆ แถวนี้ที่สามารถบอกฉันได้ว่าทำไมสิ่งเหล่านี้ถึงเป็นอย่างนั้น

บันทึกไฟล์หลัก (.shp) เป็นของendianness ผสม โดยเฉพาะบางส่วนของส่วนหัวมีการสั่งซื้อไบต์ขนาดใหญ่ของ endian แต่ระเบียนทั้งหมดเป็น endian เล็ก ๆ น้อย ๆ ฉันมักจะทำงานในระดับที่สูงกว่าไบต์และบิต แต่ทุกอย่างที่ฉันได้อ่านเกี่ยวกับ endianness ทำเครื่องหมายว่าผิดปกติ เหตุใดไฟล์จึงไม่ถูกระบุว่าเป็น endianness ที่เหมือนกัน
ฟิลด์ "ความยาวไฟล์" รวมถึงฟิลด์ความยาวและตำแหน่งอื่น ๆ จะถูกบันทึกเป็นคำ 16 บิตแทนที่จะเป็นมาตรฐานที่มากกว่า (จากมุมมองที่ จำกัด ของฉัน) การวางตำแหน่ง 8 บิต การตัดสินใจครั้งนี้มาถึงอย่างไร

ฉันโพสต์คำถามที่คล้ายกันใน Stack Overflow แต่ไม่ได้รับคำตอบใด ๆ หากสิ่งนี้ดูเหมือนจะไม่เป็นหัวข้อสำหรับคนอื่น ๆ ฉันสามารถสนับสนุนการปิดได้

shapefile

— canisrufus
แหล่งที่มา

4

Joel Lawhead ที่GeospatialPython.comได้ทำการแก้ปริศนารูปร่างไฟล์มาระยะหนึ่งแล้ว

— ชาดคูเปอร์

ไม่เกี่ยวข้องอย่างแน่นอน แต่เรียบร้อย! ฉันหวังว่าตัวเลขจะออกมา

— canisrufus

28

การพัฒนาของ Shapefiles นั้นเกิดขึ้นพร้อมกันกับการพัฒนาของ ArcView ซึ่งได้รับการออกแบบมาโดยเฉพาะให้เป็นอิสระจากแพลตฟอร์ม (อันที่จริงแล้วมันกลายเป็นความหายนะของมัน: โดยอาศัยอินเตอร์เฟสที่พัฒนาขึ้นในแพลตฟอร์ม GUI อิสระที่เรียกว่า "Neuron Data" มันไม่สามารถใช้ประโยชน์จากความสามารถของ Windows จำนวนมากมันสิ้นสุดลงด้วยการสะท้อนถึงความเลวร้ายที่สุดของระบบทั้งหมด ถูกวางตลาดแล้ว) แม้ว่าข้อมูลจำเพาะของไฟล์เชพนั้นแปลกจากจุดเริ่มต้น แต่ก็มีเหตุผลในการออกแบบ: เนื่องจาก Shapefiles มีไว้สำหรับหลาย ๆ แพลตฟอร์มสเปคของพวกเขาจึงไม่ควรเป็นประโยชน์กับคนใดคนหนึ่ง ถึงโปรแกรมเมอร์ของการโน้มน้าวใจทั้งหมด

คำถามที่สองดูเหมือนว่าจะขึ้นอยู่กับสมมติฐานที่ไม่เป็นความจริง ตัวอย่างเช่นฟิลด์ "ความยาวไฟล์" จะปรากฏที่ไบต์ออฟเซ็ต 24 ในส่วนหัวหลักและเป็นจำนวนเต็ม (ลงนาม) สี่ไบต์ (32 บิต) เนื่องจากจะต้องแสดงความยาวสูงสุด 2 ^ 31- 1 มันถูกนำหน้าด้วย "รหัสไฟล์" สี่ไบต์และอีกสี่ช่องสี่ไบต์ที่สงวนไว้สำหรับใช้ในอนาคต: เมื่อคุณจองพื้นที่ดังกล่าวแน่นอนว่าคุณต้องการทำให้เขตข้อมูลมีขนาดใหญ่ที่สุดเท่าที่จะเป็นไปได้ในเวลานั้น เป็น 32 บิตเพื่อรักษาความยืดหยุ่นที่เป็นไปได้ที่ยิ่งใหญ่ที่สุด นอกจากนี้ยังช่วยจัดแนวฟิลด์ตัวเลขในไฟล์บนขอบเขตของคำศัพท์:

— whuber
แหล่งที่มา

2

:) สิ่งที่ฉันกำลังมองหา เมื่อฉันบอกว่าช่อง "ความยาวไฟล์" คือ "บันทึกเป็นคำ 16 บิต" สิ่งที่ฉันพยายามจะพูดคือค่าของจำนวนเต็ม 32- บิตบันทึกความยาวของไฟล์เป็นคำ 16 บิต (จากข้อมูลจำเพาะ: "ค่าสำหรับความยาวไฟล์คือความยาวทั้งหมดของไฟล์เป็นคำแบบ 16 บิต") ดูเหมือนว่ามันสามารถเป็นตัวแทนความยาวไบต์ของ 2 * 2 ^ 31-1 ซึ่งมีขนาดประมาณ 4 GB เช่นเดียวกับค่าในไฟล์. shx ดูเหมือนว่าควรจะรองรับความยาวไฟล์ได้สูงสุด 2 * 2 ^ 31-1 ไบต์ ฉันพลาดอะไรไป

— canisrufus

จุดดี - ฉันพลาดนั่น ที่จริงแล้วการออกแบบอาจทำให้ความยาวของไฟล์และออฟเซ็ตได้ง่าย (ตัวชี้ในไฟล์. shx) ในแง่ของคำสี่ไบต์ซึ่งจะเป็นการเพิ่มขนาดที่เป็นไปได้ของไฟล์. shp เป็น 4 * (2 ^ 31-1) (ประมาณ 8 พันล้านไบต์) ฉันไม่รู้ว่าทำไมพวกเขาจึงเลือกคำสองไบต์หรือแม้แต่ทำไมพวกเขาจึงใช้จำนวนเต็มที่ลงนามอย่างต่อเนื่องโดยที่จำนวนเต็มที่ไม่ได้ลงชื่อมีความเหมาะสมมากกว่า

— whuber

1

ฉันสงสัยว่าแปลกประหลาด 16 บิตจะทำอย่างไรกับคอมพิวเตอร์ 16 บิตที่ใช้ในเวลาที่มีพื้นเมืองintเป็น 16 บิต

— Mike T

มันเป็นไปได้เสมอ @Mike อย่างไรก็ตามแม้กระทั่งพีซี 80286 เครื่อง (c. 1984) ก็รองรับ 32 บิตได้เช่นกัน - พวกเขาใช้คู่ทะเบียนเพื่อทำเลขคณิตกับพวกเขา

— whuber

5

เพื่อนร่วมงานของ Esri กล่าวว่าเขาจำได้ว่าการผสมผสานของ endian-ness นั้นเป็นการไตร่ตรองอย่างรอบคอบ มีบางอย่างในบรรทัดของ 'เราจะทำให้นักพัฒนาจัดการได้อย่างสมบูรณ์เพราะปัญหาข้ามแพลตฟอร์ม' แต่แน่นอนว่านี่คือหลักฐานทั้งหมด

— mkennedy

10

บางคนที่นั่นรู้คำตอบเหล่านี้และอีกมากมาย แต่พวกเขาไม่ได้พูด

ทีมที่ฉันทำงานด้วยเพื่อถอดรหัสไฟล์ sbn และ sbx ที่ไม่มีเอกสารได้ค้นพบสิ่งแปลกประหลาดมากมายที่มีทั้งความคล้ายคลึงกัน แต่มีความแปลกประหลาดมากขึ้นในเวลาเดียวกัน

โครงสร้าง Shapefile ส่วนใหญ่มีเหตุผลและมีประสิทธิภาพมากซึ่งแนะนำให้นักพัฒนา ESRI คิดถึงสิ่งต่างๆ มันเหมือนกับว่าพวกเขามีนักพัฒนาที่ชาญฉลาดจำนวนหนึ่งที่มีคนบ้าถูกโยนเข้ามา

ตามที่แนะนำโดยโพสต์อื่น ๆ ที่แปลกประหลาดอาจเป็นผลมาจากข้อกำหนดของเครื่องหรือภาษาที่ต่างประเทศให้เราตอนนี้

ฉันมักจะสงสัยว่าคำ 16 บิตเป็นวิธีที่ง่ายในการประหยัดพื้นที่ คุณจะพบว่าคุณต้องเก็บค่าคำ 16 บิตในหน่วยความจำเมื่อจัดการไฟล์ กลยุทธ์การคำนวณค่าเพื่อประหยัดพื้นที่เป็นเรื่องธรรมดาในรูปแบบไบนารีแม้กระทั่งทุกวันนี้ แต่ข้อเสนอแนะดั้งเดิมของไมค์ก็เป็นไปได้เช่นกัน

การพลิกคว่ำเป็นเรื่องแปลก ไม่มีใครมีคำตอบที่ดีที่ฉันเคยเห็น

รูปแบบ dbf ถูกคัดลอกมาจากรูปแบบ dbase III ซึ่งมีต้นกำเนิดในปี 1960 มีการใช้กันอย่างแพร่หลายนับตั้งแต่และสามารถพบได้ในชื่ออื่น ๆ รวมถึง foxpro และ xbase

แม้จะมีข้อบกพร่องรูปแบบแปลกประหลาดและข้อ จำกัด ของรูปแบบ Shapefile ยังคงมีอยู่ในและรอบ ๆ สนามของ GIS ทุกความพยายามที่จะแทนที่มันได้รับการบวมเกินไปสำหรับการจัดเก็บแบบเวกเตอร์ง่ายหรือเป็นกรรมสิทธิ์เกินไป แม้แต่ ESRI ก็คิดว่ารูปร่างไฟล์เป็นของเล่นที่จะช่วยให้ผู้เริ่มต้นไปยัง ArcINFO ความครอบคลุมและฐานข้อมูลทางภูมิศาสตร์ อินเทอร์เน็ตอาจมีส่วนเกี่ยวข้องกับรูปแบบการถอด

ฉันเรียนรู้การเขียน pyshp มากมาย การเขียนโปรแกรมแยกวิเคราะห์เป็นวิธีที่ยอดเยี่ยมในการเรียนรู้รูปแบบ

— GeospatialPython.com
แหล่งที่มา

อืมมม คำตอบที่ดี. ฉันไม่เข้าใจว่าการใช้คำ 16 บิตช่วยประหยัดพื้นที่ได้อย่างไร เพื่อจุดประสงค์ของฉัน (การสร้าง ArrayBufferViews ใน javascript) ทั้งหมดนี้คือการบังคับให้ฉันคูณสองเพื่อให้ได้ออฟเซ็ตที่ถูกต้อง: ฉันกำลังเขียนวงจรเพิ่มเติมโดยไม่มีประโยชน์ คุณจะทำอย่างละเอียด?

— canisrufus

1

ใช่ - เนื่องจากพวกเขาใช้ ints ที่ลงนามแล้วพวกเขาจะได้ค่า 32,767 ดังนั้นพวกเขาจึงสามารถเก็บตัวเลขที่ใหญ่กว่าใน 2 ไบต์แทนที่จะเป็น 4 ค่าที่กำหนดให้กับคำ 16 บิตตามที่ฉันบอกว่าเป็นค่าที่คุณถือท้าย RAM เมื่อทำงานกับ shapefiles สำหรับการอ่านและการเขียน มากับรูปแบบการประหยัดพื้นที่ในคู่ (ซึ่งฉันได้เห็นในรูปแบบไบนารีอื่น ๆ ) น่าเกลียดและซับซ้อนอยู่เสมอ ดังนั้นพวกเขาจึงติดอยู่กับแบบแผนง่ายๆสำหรับค่าขนาดข้อมูล

— GeospatialPython.com

นอกจากนี้ - ฉันค้นพบในไฟล์ shx ซึ่งทำให้ฉันนิ่งงันในตอนแรก ไฟล์ SHX มีกรอบสำหรับคุณสมบัติที่แมปกับกริดจำนวนเต็ม 256x256 เทคนิคนี้เป็นเรื่องธรรมดาในการจัดทำดัชนี แต่ไม่ได้อยู่ในกริดที่มีขนาดเล็ก พวกเขาบันทึกพิกัดเป็นตัวอักษร 1 ไบต์แทน ints นั่นเป็นเหตุผลที่กริดเป็น 256x256 เท่านั้น ตอนนี้กำลังตระหนี่อย่างจริงจังกับความทรงจำแม้กระทั่งช่วงปี 1990! มีแน่นอนประสิทธิภาพอื่น ๆ อีกมากมายเช่นการจัดกลุ่มชิ้นส่วนโดยนัยโดยใช้ดัชนี คุณพูดถูก - เทคนิคเหล่านี้สร้างภาระให้กับโปรแกรมเมอร์มากขึ้น ดังนั้นการใช้หน่วยความจำจะต้องมีความสำคัญ

— GeospatialPython.com

1

ฉันอ่านบทความของคุณ คุณกำลังทำผลงานที่ดีของลอร์ดในเรื่องนั้น;) ฉันกำลังรอการวิเคราะห์ขั้นสุดท้ายของคุณ เกี่ยวกับปัญหา 16 บิตฉันไม่แน่ใจว่าประเด็นของคุณเป็นเช่นไร 1. ในไฟล์ SHP และ SHX ไม่มีเขตข้อมูล 16 บิตเว้นแต่ว่าฉันเข้าใจผิดอย่างมาก 2. การแทนค่า 16- บิตแทนค่า 8 บิตเพียงสองเท่าของความยาวที่อธิบายได้ (2 * 2 ^ 15) ซึ่งสามารถทำได้โดยการใช้ int ที่ไม่ได้ลงนาม (2 ^ 16) ในที่สุดมันก็ไม่ได้ช่วยประหยัดพื้นที่

— canisrufus

เมื่อคุณอ้างถึง "การใช้งานหน่วยความจำ" เป็นการยากที่จะบอกว่าคุณหมายถึง RAM หรือดิสก์ ในช่วงต้นยุค 90 ไดรฟ์ 2 GB และ RAM ขนาด 16-32 MB นั้นค่อนข้างระดับไฮเอนด์: การประหยัดพื้นที่ไฟล์บางส่วน (หรือแบนด์วิดท์เครือข่าย) จะยังคงมีความสำคัญ วิศวกรซอฟต์แวร์ที่มีความรับผิดชอบต้องการที่จะคิดอย่างรอบคอบผ่านความหมายสำหรับลูกค้าในอนาคตของพวกเขาในการแลกเปลี่ยนเวลาในตัวเลือกของพวกเขา; ในการเข้าใจถึงปัญหาหลังเกิดฉันจะให้พวกเขาได้รับประโยชน์จากความสงสัยนอกเสียจากว่าทางเลือกจะเห็นได้ชัด

— whuber

5

นี่คือสิ่งที่ฉันทำ

รูปแบบ Shapefile มีแนวโน้มมากที่สุดที่พัฒนาจาก ARC / INFO ซึ่งมีประวัติย้อนหลังไปจากต้นกำเนิด FORTRAN / PR1ME รูปแบบ ARC / INFO ทั้งหมดมีส่วนหัวขนาด 100 ไบต์และมีจุดสิ้นสุดขนาดใหญ่ของรหัสไฟล์และความยาวไฟล์ (เช่นความครอบคลุม, TINs)

เมื่อ Shapefiles ถูกสร้างขึ้นสำหรับ ArcView 1, ESRI มุ่งเน้นไปที่การเจาะเข้าไปในตลาด Microsoft Windows และส่วนที่เหลือของรูปแบบ Shapefile นั้นมุ่งเน้นอย่างมากในการเป็นพีซี endian เล็ก ๆ น้อย ๆ

การสลับสับเปลี่ยนระหว่าง endianess คือคงต้องสนับสนุนต้นกำเนิดดั้งเดิมในขณะที่คาดหวังผลประโยชน์ในการบุกเข้าไปในแพลตฟอร์ม

— Stephen Quan
แหล่งที่มา

ฟังดูน่าเชื่อถือ ขอบคุณสำหรับความเข้าใจ!

— whuber

นี่คือการคาดเดาที่ชื่นชอบเกี่ยวกับ endianness ตอนนี้สิ่งที่เราต้องการคือ Dangermond เพื่อเผยแพร่ "The ESRI Tell All, Technical Edition" เพื่อดูว่าคุณพูดถูกหรือเปล่า!

— canisrufus

2

หากรูปแบบ shapefile วิวัฒนาการมาจากรูปแบบ ARC / INFO รูปแบบนี้จะเร็วกว่า v7 มาก ในปี 1994 เมื่อฉันเริ่มต้นที่ ESRI, AV2 ได้ออกไปแล้วและงานพัฒนาสำหรับ ARC / INFO 7 นั้นกำลังดำเนินการอยู่

— mkennedy

จุดดี Melita ปมของการตอบกลับนี้ - ในที่สุดตัวเลือกการจัดรูปแบบบางอย่างอาจมีต้นกำเนิดของ Fortran - จะยังคงเป็นความจริงตลอดทางกลับไปที่แอปพลิเคชั่น Arc และ Info ดั้งเดิม

— whuber

ขอบคุณ @mkennedy ฉันลบการอ้างอิงถึง v7 ฉันยังจำวันที่คู่มือผู้ใช้ ARC / INFO ดั้งเดิม (v3 .. v6 era) มีส่วนหัวซึ่งฉันเชื่อว่าถูกพรากไปจากรหัส FORTRAN

— Stephen Quan

4

ฉันมักจะสันนิษฐานว่าการแยก endian เกิดจากการมีสองทีมหนึ่งใน Sun Workstations และอีกอันบนพีซีและพวกเขาไม่ได้พบกันจนกระทั่งใกล้จะสิ้นสุดกระบวนการพัฒนา

ฉันชอบที่จะรู้ว่าสิ่งที่เกิดขึ้นจริง

— Ian Turton
แหล่งที่มา

3

ฉันคิดว่า ESRI มีการประสานงานมากกว่านั้นเล็กน้อย อันที่จริงหากมีสิ่งใดซอฟต์แวร์ของพวกเขามีแนวโน้มที่จะดูเหมือนว่ามีส่วนร่วมของคณะกรรมการมากเกินไปในการออกแบบ

— whuber

0

ฉันคิดว่าอยู่ที่ไหนซักแห่งฉันได้ยินเรื่องเกี่ยวกับการกำเนิดของ dbf / foxpro
นั่นอาจเป็นเพียงความฝันแปลก ๆ ที่ฉันเคยคิด

— Brad Nesom
แหล่งที่มา

5

ส่วน. shp และ. shx ซึ่งเป็นปัญหาที่นี่ได้รับการออกแบบอย่างสมบูรณ์โดยอิสระจากรูปแบบ. dbf ซึ่งมีมานานเกือบ 20 ปีก่อนหน้านี้

— whuber

0

คุณต้องเข้าใจรูปร่างของไฟล์ที่ถูกนำมาใช้เมื่อ 20 ปีก่อนในเวลานั้นมีรูปแบบไฟล์ที่ไม่สอดคล้องกันและมีการออกแบบที่ไม่ดีดังนั้นรูปร่างของไฟล์จึงไม่มีข้อยกเว้น ฉันเขียนตัวแยกวิเคราะห์ shapefile ด้วยตัวเองและฉันต้องบอกว่าฉันมีปัญหามากมายเกี่ยวกับการแยกวิเคราะห์รูปแบบ DBF เปรียบเทียบกับ shapefiles (.SHP) ด้วยตัวเอง

— Igor Brejc
แหล่งที่มา