การออกแบบ API สำหรับข้อมูลเชิงพื้นที่

ฉันกำลังพิจารณาที่จะสร้าง API เพื่อให้สามารถใช้ชุดข้อมูลเชิงพื้นที่สำหรับเพื่อนร่วมงานเพื่อการวิเคราะห์ได้

ส่วนหนึ่งของงานของฉันคือการวิเคราะห์และเตรียมข้อมูลที่สามารถนำไปใช้สำหรับการวิเคราะห์เพิ่มเติมโดยผู้อื่น งาน (ขณะที่ขนาดเล็กและซับซ้อนน้อยกว่า) คล้ายกับwalkscoreแต่เกี่ยวข้องกับชุดข้อมูลขนาดใหญ่บางส่วน มีข้อ จำกัด ที่เพิ่มขึ้นเกี่ยวกับวิธีที่ฉันสามารถแบ่งปันข้อมูลดั้งเดิมได้ แต่งานที่ลอกเลียนแบบของฉันนั้นสามารถแบ่งปันได้ ฉันคิดเกี่ยวกับวิธีที่ดีที่สุดในการแบ่งปันผลการวิเคราะห์ของฉัน (นอกจากการส่งผ่านชุดข้อมูลขนาดใหญ่) และคิดว่า API จะเป็นวิธีการหนึ่ง ฉันควรคิดถึงสิ่งใดเมื่อสร้าง API มีข้อกำหนดการออกแบบที่ฉันสามารถทำตามได้หรือไม่?

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

โดย API ฉันคิดว่าคุณหมายถึงการเข้าถึงข้อมูลของคุณผ่านเครือข่ายประเภท HTTP POST / GET เช่น Google Maps API หรือไม่ มันจะเป็นข้อมูลแบบแรสเตอร์หรือเวกเตอร์ ฉันจะถือว่าเวกเตอร์สำหรับจุดประสงค์ของการสนทนานี้ นี่เป็นเพียงโปรโตคอลการสื่อสารมากกว่า Application Programming Interface

คุณไม่จำเป็นต้องออกแบบอะไรตั้งแต่ต้นเพราะมีโปรโตคอลมาตรฐานมากมาย (แทนที่จะเป็น API ต่อ se ฉันมีข้อผิดพลาดเล็กน้อยเกี่ยวกับการเรียกสิ่งต่าง ๆ เมื่อพวกเขาไม่ได้ แต่ฉันจะไม่เบื่อคุณ! ) หากคุณสนใจที่จะให้บริการข้อมูลเวกเตอร์แบบอ่านอย่างเดียวให้กับลูกค้าของคุณคุณต้องใช้เซิร์ฟเวอร์ WFSที่อยู่หน้าฐานข้อมูลของคุณ ผมเคยใช้GeoServerในอดีต แต่ฉันชอบ lightweigtness ของTinyOWS ทั้งสองทำงานเดียวกัน: กำหนดค่าให้เข้าถึงฐานข้อมูลของคุณจากข้อมูลตั้งค่าให้ทำงานเป็นส่วนหนึ่งของเว็บเซิร์ฟเวอร์ ( Apacheเป็นเรื่องปกติ แต่ฉันชอบlighttpd) และที่นั่นคุณมีมัน QGIS สามารถโหลดข้อมูลจากเซิร์ฟเวอร์ WFS และไม่ต้องสงสัยเลยว่า Arc สามารถทำได้ OpenLayers ยังมีความสามารถในการเรนเดอร์ WFS สำหรับโซลูชันบนเบราว์เซอร์ ในระดับที่ต่ำกว่าสามารถใช้ GDAL เพื่อแปลงข้อมูลจาก WFS เป็นรูปแบบเวกเตอร์ใดก็ได้ที่รองรับ OGR

หากคุณต้องการความสามารถในการแก้ไขทั้ง GeoServer และ TinyOWS รองรับ WFS-T ทำให้ผู้ใช้ของคุณอัปโหลดการวิเคราะห์กลับไปยังเซิร์ฟเวอร์ของคุณ

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

คุณมีทางเลือกสองทาง ตัวเลือกที่จะขึ้นอยู่กับตัวแบบข้อมูลของคุณชนิดของข้อมูลที่จะให้บริการรูปแบบการใช้งานที่ต้องการการควบคุมการเข้าถึงรวมถึงแพลตฟอร์มของการส่ง (เว็บ HTML, Java Server, IIS, ชุดข้อมูลแบบคงที่)

1. ขยายผลิตภัณฑ์ที่มีอยู่เพื่อใช้ชุดข้อมูลของคุณ คุณสามารถดูการโฮสต์อินสแตนซ์GeoServerบนคอมพิวเตอร์ (หรือเฉพาะของคุณ) และส่งข้อมูลของคุณในแบบนั้น หากข้อมูลของคุณไม่อยู่ในรูปแบบที่ GeoServer สามารถเข้าใจได้คุณมีตัวเลือกในการเขียนแพ็คเกจ Java เพื่อให้ความสามารถนั้น ข้อดีคือคุณมีมาตรฐานที่กำหนดไว้อย่างดีสำหรับการส่งข้อมูลเชิงพื้นที่สำหรับการสร้างภาพ (WMS) และการจัดการ / ดาวน์โหลด (WFS) รวมถึงผลประโยชน์อื่น ๆ เช่น geocaching และการเรียงต่อกัน
2. ใช้ตัวเลือก API ของคุณและคุณสามารถควบคุมวิธีการที่ผู้ใช้ติดต่อกับมันได้อย่างเต็มที่ สิ่งแรกที่คุณต้องทำคือกำหนดว่าคุณต้องการให้ผู้ใช้โต้ตอบกับข้อมูลของคุณอย่างไร อินเทอร์เฟซสำหรับข้อมูลของคุณจะเป็นกุญแจสำคัญระหว่างความสำเร็จหรือความล้มเหลว หากอินเทอร์เฟซของคุณเปิดอยู่เกินไปมันอาจซับซ้อนและใช้ไม่ได้ง่ายเกินไปและ จำกัด ช้าหรือไม่มีการยอมรับ ไม่ว่าจะด้วยวิธีใดการกำหนดวิธีที่คุณต้องการให้ผู้ใช้เข้าถึงข้อมูลของคุณและวิธีที่คุณคาดว่าผู้ใช้จะต้องการใช้ข้อมูลของคุณจะมีความสำคัญ

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