การทดลองของ ShadeMap ที่ใช้ LiDAR คำนวณแม้แต่เงาของต้นไม้
(tedpiotrowski.svbtle.com)- ที่ผ่านมา ShadeMap คำนวณเงาด้วย ข้อมูลความสูงแบบเรดาร์ ที่หาได้ง่ายทั่วโลก แต่ในพื้นที่ที่มีต้นไม้จำนวนมาก การคาดการณ์แสงแดดโดยตรงอาจคลาดเคลื่อนได้มาก
- LiDAR สามารถสะท้อนความสูงได้ละเอียดกว่า ไม่ใช่แค่พื้นดิน แต่รวมถึงวัตถุอย่างต้นไม้และอาคารด้วย ทำให้จำลองเงาของพืชพรรณตามฤดูกาลและช่วงเวลาได้
- ด้วย ชุดข้อมูล LiDAR แบบเปิดของรัฐวอชิงตัน จึงสามารถทดลองเรนเดอร์พื้นที่จริงอย่าง Seattle metropolitan area โดยรวมเงาของต้นไม้เข้าไปด้วยได้
- เมื่อนำไปใช้กับบริการจริง ยังมีภาระเรื่องการแปลง GeoTIFF ระดับ 100GB ให้เป็น image tile สำหรับเบราว์เซอร์ รวมถึงข้อจำกัดด้านหน่วยความจำและพื้นที่จัดเก็บ
- แม้แต่การแปลง Seattle metropolitan area ก็ยังคืบหน้าได้เพียงราวครึ่งหนึ่งหลังผ่านไป 12 ชั่วโมง และ tile มีขนาดเกิน 15GB ทำให้การเปิดให้ใช้งานสาธารณะยังถูกจำกัดไว้เป็นเดโมขนาดเล็กเพราะต้นทุน
เหตุผลที่ ShadeMap ไม่มีเงาของต้นไม้มาก่อน
- ShadeMap จำลองเงาโดยใช้ข้อมูลความสูง และชุดข้อมูลความสูงที่หาได้ง่ายทั่วโลกคือ ข้อมูลแบบเรดาร์อย่าง SRTM
- เรดาร์ทำงานได้แม้ในเวลากลางคืนและทะลุผ่านเมฆได้ ทำให้ดาวเทียมเก็บข้อมูลจากอวกาศได้ตลอด 24 ชั่วโมง
- ในการเปรียบเทียบการเรนเดอร์ของ Bainbridge Island เวลา 7:09 น. วันที่ 9 กรกฎาคม ข้อมูลแบบเรดาร์สะท้อนพืชพรรณได้ไม่เพียงพอ ทำให้เงาจำนวนมากหายไป
- จากคำอธิบายเริ่มแรกที่บอกว่าเรดาร์สะท้อนจากพื้นดินเท่านั้น มีผู้ใช้ HN ชี้ว่าเรดาร์ก็สะท้อนจากพื้นผิวอย่างพืชพรรณได้เช่นกัน และภายหลังมีการแก้ไขเพิ่มเติม
- เนื่องจากมีการอ้างถึงชุดข้อมูลเรดาร์ SRTM ว่าเป็นแหล่งของข้อมูลความสูงพื้นดิน จึงทำให้เกิดสมมติฐานดังกล่าว
- ในทางกลับกัน LiDAR แม่นยำกว่า แต่ต้องเก็บข้อมูลด้วยเครื่องบินหรือโดรน และไม่สามารถทะลุหมอกกับเมฆได้
- การเก็บข้อมูลใช้ทั้งเวลาและค่าใช้จ่ายสูง จึงเป็นโครงสร้างที่หน่วยงานท้องถิ่นแต่ละแห่งต้องรับภาระค่าทำสำรวจ
ภาระของการแปลงข้อมูล LiDAR เป็น tile สำหรับเบราว์เซอร์
- รัฐวอชิงตันมี ชุดข้อมูล LiDAR ที่ครอบคลุมพื้นที่กว้าง และเมื่อนำมาใช้ก็ช่วยปรับปรุงการจำลองเงาต้นไม้ของ ShadeMap ได้
- ข้อมูลต้นฉบับอยู่ในรูปแบบ GeoTIFF ที่ออกแบบมาสำหรับซอฟต์แวร์ GIS แบบดั้งเดิม จึงไม่เหมาะกับการโหลดเร็วในเบราว์เซอร์แบบ JPG หรือ PNG
- งานแปลงข้อมูลคือการตัดไฟล์ GeoTIFF แบบ floating point ขนาดหลายร้อย GB ที่ใช้หน่วย imperial feet ให้เป็น image tile ขนาดเล็ก แล้วเข้ารหัสค่า metric meters ลงในค่า pixel สีแดง เขียว และน้ำเงิน
- ระหว่างทำงาน ผู้เขียนต้องซื้อฮาร์ดไดรฟ์ 1TB และถาม ChatGPT เรื่องวิธีแปลงข้อมูลไปด้วย
- ด้วย RAM 16GB จึงยากที่จะโหลดไฟล์ข้อมูลขนาดใหญ่ทั้งหมดพร้อมกัน ทำให้ต้องเขียนโค้ดแปลงใหม่ให้ประมวลผลเป็นพื้นที่ย่อย แทนที่จะทำทั้งแผนที่ในครั้งเดียว
- แค่แปลง Seattle metropolitan area ก็ยังเสร็จเพียงราวครึ่งหนึ่งหลังผ่านไป 12 ชั่วโมง และ tile ที่สร้างขึ้นก็มีขนาดเกิน 15GB แล้วพร้อมจะเพิ่มขึ้นต่อ
- แม้ผลลัพธ์จะน่าประทับใจ แต่ค่าใช้จ่ายในการโฮสต์ข้อมูลแบบสาธารณะยังเป็นภาระ จึงเปิดให้ดูได้เฉพาะพื้นที่เล็ก ๆ เป็น เดโม ในตอนนี้
- หลังการอัปเดต shademap.app สามารถให้บริการข้อมูล LiDAR แบบบล็อกขนาด 1 ตารางกิโลเมตรสำหรับพื้นที่ขนาดใหญ่ของโลกได้แล้ว
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เดโมนี้ เจ๋งมากและเร็วมาก. ตอนนี้กำลังสร้างคลัง/แพลตฟอร์มขนาดใหญ่สำหรับวิเคราะห์แผนที่เก่าและภาพถ่ายทางอากาศ(https://pastmaps.com - ยังอยู่ช่วงเริ่มต้นมาก ๆ อย่าดูแรงเกินไป) และทำงานกับไพป์ไลน์การไทล์กับ GeoTIFF ค่อนข้างเยอะ
คล้ายกันคือเคยมีปัญหาเมื่อใช้ไฟล์ GeoTIFF ต้นฉบับเป็นแหล่งข้อมูล และสามารถเลี่ยงความจำเป็นในการไทล์ได้ด้วยการเพิ่ม HTTP range requests ให้กับไฟล์สแตติกที่อัปขึ้น S3 แล้วสร้าง custom tiling hook ภายใน MapLibre
มันผลักภาระการคำนวณไปที่ฝั่งไคลเอนต์ แต่ก็ยังทำงานได้ค่อนข้างเร็วแม้บนอุปกรณ์มือถือรุ่นเก่า
ถ้าสนใจการรองรับ GeoTIFF source ของ MapLibre ก็ยินดีแชร์โค้ดพื้นฐานหรือโอเพนซอร์สบางส่วนของงานนั้นได้ นึกว่าบนอินเทอร์เน็ตจะมีแค่ผมคนเดียวที่หมกมุ่นกับของแบบนี้ :D
ในกรณีของผม LiDAR GeoTIFF ใช้หน่วยฟุตแบบอังกฤษและความละเอียดแบบ 32-bit floating point ถ้ากำหนดช่วงความสูงตั้งแต่ระดับน้ำทะเลถึงเอเวอเรสต์เป็นเมตร(8848) แล้วเก็บลงใน int16 จะได้ ความละเอียด 0.2 เมตร
สำหรับ ShadeMap แค่นั้นก็พอ ดังนั้นถ้าเปลี่ยนจาก float32 เป็น int16 ในทางทฤษฎีก็จะลดพื้นที่เก็บข้อมูลบนคลาวด์ได้ครึ่งหนึ่ง และถ้าคิดรวมการบีบอัด PNG ก็อาจลดได้มากกว่านั้น
https://www.cogeo.org/
OpenLayers รองรับ: https://openlayers.org/en/latest/examples/cog.html
เท่าที่รู้ MapLibre กับ Leaflet ยังไม่มีการรองรับในตัว
ผมสนใจด้านนี้มาก และกำลังคิดรวมถึงการสนับสนุนบางโปรเจ็กต์ในเชิงการเงินด้วย ได้อีเมลหา Ted ไปแล้ว แต่ก็อยากคุยกับใครก็ตามที่ทำงานแบบนี้ อีเมลอยู่ในโปรไฟล์
โชคดีที่มันเฉพาะทางพอจนไม่ต้องกลัวว่าอินบ็อกซ์จะระเบิด
ผมเองก็ต้องเรียนรู้อีกว่าปัญหาในฟอร์แมต GeoTIFF อยู่ตรงไหนแน่ ๆ บางทีการแชร์โครงสร้างพื้นฐานของ ไพป์ไลน์แปลงข้อมูลล้วน ๆ ระหว่างสองโปรเจ็กต์อาจช่วยได้
ถ้ามีคนสองคนที่ชนกำแพงเดียวกัน ก็อาจมีคนอื่นอีก
คำอธิบายที่ว่า “เรดาร์พลาดเงาที่เกิดขึ้นถึง 90% อย่างชัดเจน เพราะมันไม่รวมพืชพรรณ เรดาร์สะท้อนจากพื้นดินเท่านั้น จึงมองไม่เห็นวัตถุอย่างต้นไม้และอาคาร” ดูเหมือนจะไม่ถูกต้อง
เรดาร์ในบางย่านความถี่สามารถมองทะลุใบไม้ได้ ซึ่งเรียกว่า FOPEN สำหรับระยะและความเร็วในการครอบคลุมที่ต้องใช้ในการทำแผนที่ภูมิประเทศ ผมไม่แน่ใจว่าเรดาร์จะมองทะลุอาคารได้หรือไม่
Shuttle Radar Topography Mission ที่บทความพูดถึงน่าจะใช้เรดาร์ย่าน C-band หรือ X-band ซึ่งทั้งคู่ควรสะท้อนจากพืชพรรณและอาคาร
โดยที่ยังไม่ได้ลงลึกมาก เหตุผลที่ข้อมูลเรดาร์ไม่มีเงาของพืชพรรณและอาคารอาจเป็นเพราะ 1) ความละเอียดของข้อมูลเรดาร์ต่ำเกินไป(หลายสิบเมตรขึ้นไป), 2) ถูกลบออกระหว่างโพสต์โปรเซสจากการผ่านตรวจหลายเรขาคณิต, หรือ 3) มุมตกกระทบของเรดาร์ต่ำจนแทบไม่เกิดเงาตั้งแต่แรก
สำหรับคำถามที่ว่าเรดาร์สุ่มตัวอย่างยอดไม้หรือพื้นดิน FAQ อธิบายว่า มันไม่สามารถมองทะลุเรือนยอดพืชพรรณที่หนาแน่นได้ อาจแทรกเข้าไปในเรือนยอดได้บ้างเล็กน้อย แต่โดยทั่วไปจะตามบริเวณใกล้ยอดเรือนยอดด้านบน
ปัญหาคือสัญญาณเรดาร์สะท้อนจากยอดไม้ จากภูมิประเทศ หรือเป็นการผสมกันของทั้งสองแบบ นักภูมิสารสนเทศสนใจภูมิประเทศ ส่วนงานวิจัยป่าไม้สนใจความสูงของเรือนยอด
ความยาวคลื่นที่ใช้คือ 5.6 ซม. ซึ่งทะลุพืชพรรณได้ไม่ดี จึงทำแผนที่ใกล้บริเวณยอดเรือนยอดในพื้นที่ที่มีพืชพรรณปานกลางถึงหนาแน่น งานวิจัยที่เทียบกับ laser altimeter พบว่ามันทะลุเข้าไปได้เล็กน้อยแต่ไม่ถึงพื้นดิน ถ้าพืชพรรณโปร่งหรือไม่มีใบ ก็อาจได้สัญญาณสะท้อนจากพื้น Earth Observing System เคยวางแผนจะมี Vegetation Canopy Lidar เพื่อให้ความสามารถนี้และทำให้เปรียบเทียบชุดข้อมูลได้อย่างน่าสนใจ
https://www2.jpl.nasa.gov/srtm/faq.html
เงาจากภูเขาเป็นปัญหาจริง บางรุ่นมีพื้นที่ว่างอยู่ โดยเฉพาะบริเวณใกล้เทือกเขาหิมาลัยซึ่งไม่มีสัญญาณสะท้อนเรดาร์ ถ้าสนใจมีงานวิจัยเกี่ยวกับการเติมช่องว่างในข้อมูล SRTM อยู่พอสมควร
หากมี pipeline ที่ประมวลผลล่วงหน้า GeoTIFF และมีระบบที่ให้ข้อมูลระดับความสูงภูมิประเทศแก่ผู้ใช้อยู่แล้ว ก็น่าจะเข้ารหัสเฉพาะ ความต่างระหว่าง LiDAR กับเรดาร์ ลงในไทล์ แล้ววางข้อมูลต้นไม้ทับบนข้อมูลภูมิประเทศเดิมได้เหมือนกัน วัตถุที่จะเข้ารหัสกับความละเอียดที่ต้องการน่าจะใส่ได้ในระดับราว 4 บิต และเพราะมีค่า 0 เยอะก็น่าจะหายไปได้มากจากการบีบอัด เป็นความคิดที่ค่อนข้างใกล้เคียงกับการระดมสมองเฉยๆ
height = -10000 + ((R * 256 * 256 + G * 256 + B) * 0.1)[mapbox/maptiler]height = (R * 256 + G + B / 256) - 32768[mapzen terrarium]ถ้าต้องการแค่ระดับความสูงเหนือระดับน้ำทะเล (0~8848m) ก็สามารถเก็บข้อมูลไว้ใน 2 ไบต์ พร้อมคงความละเอียด 0.13m ได้ ส่วนความละเอียดของ Mapbox คือ 0.1m
height = (R * 256 + B) / (256 * 256) * 8848[shademap]มีแผนจะใช้การเข้ารหัสนี้ ทดลองแล้วและช่วยประหยัดพื้นที่ ยังไม่แน่ใจเรื่องเวลาในการประมวลผล
การเข้ารหัสที่ดีที่สุดคือใส่ระดับความสูงต่ำสุดของทั้งไทล์ไว้ในเฮดเดอร์ แล้วเก็บเฉพาะ ค่าผลต่าง ระหว่างระดับต่ำสุดของไทล์กับระดับความสูงของแต่ละพิกเซล แบบนี้มีประสิทธิภาพด้านพื้นที่ดีที่สุด แต่ต้องโหลดข้อมูลทั้งไทล์ขึ้นหน่วยความจำเพื่อหาระดับต่ำสุด จึงมีประสิทธิภาพน้อยกว่าการเข้ารหัสแบบสตรีมทีละพิกเซล
ถ้าช่วยบอกได้ว่าควรเรียนอะไรเพื่อให้ชำนาญ วิทยาศาสตร์ข้อมูลเชิงภูมิประเทศ ก็คงดีมาก
ชอบ Shademaps มาก อยากให้ผลิตภัณฑ์ของผมที่ใช้สิ่งนี้ประสบความสำเร็จกว่านี้ แต่ Ted กับ Shademaps เจ๋งมาก การเพิ่มต้นไม้เข้ามาใช้งานได้จริงมาก หลายพื้นที่ที่ใช้เครื่องมือนี้เป็นเขตเมืองก็จริง แต่ถ้าไม่ใช่ ข้อมูลต้นไม้ แทบจะสำคัญกว่าตึกหรือความสูงเสมอ Ontario ค่อนข้างราบ และผู้ใช้ของผม 99% อยู่ที่นั่น
ฟังดูเหมือนคำถามสัมภาษณ์งานบริษัท GIS: “ถ้ามีข้อมูลเรดาร์กับ LiDAR และอยาก รวม มันบนอุปกรณ์ที่หน่วยความจำจำกัด คุณจะทำอย่างไร?”
บริการแผนที่ของฝรั่งเศสเริ่มทำ การสำรวจ LiDAR ความละเอียดสูง ครอบคลุมทั้งฝรั่งเศสแล้ว และบางส่วนก็เปิดให้ใช้แล้ว: https://geoservices.ign.fr/lidarhd อยู่ด้านล่าง
สงสัยว่ามีแผนจะนำข้อมูลนี้เข้าแอปในอนาคตไหม
ตอนนี้อุปสรรคหลักคือคู่หมั้นของผมปิดเทอมฤดูร้อนอยู่ (เป็นครู) เลยออกไปข้างนอกกันบ่อย และการหา ชุดข้อมูล LiDAR ทางออนไลน์ก็ยากเหมือนกัน
ข้อมูลของ Washington เหมือนจะมีมานานพอสมควรแล้ว แต่ผมไม่รู้ว่ามันมีอยู่จนกระทั่งไม่กี่สัปดาห์ก่อน
สักวันหนึ่งหวังว่าจะตั้ง ASK HN เกี่ยวกับชุดข้อมูล LiDAR แล้วคราวด์ซอร์สข้อมูลให้ได้มากที่สุด
เป็นโปรเจ็กต์ที่เจ๋งมาก
ลองโฮสต์ข้อมูลไว้ใน S3 bucket ที่เปิด Requestor Pays เป็นอย่างไร? แบบนั้นก็รับภาระแค่ค่าจัดเก็บข้อมูล
การเข้าถึงแบบ anonymous จะทำไม่ได้ (เหมือนกับการแชร์ผ่าน Dropbox) แต่ค่าใช้จ่ายจะลดลงมาก
https://docs.aws.amazon.com/AmazonS3/latest/userguide/Reques...
เพราะเป็นแบบอ่านอย่างเดียว จึงไม่จำเป็นต้องมี SQL frontend โดยเฉพาะ และก็มีหลายวิธีที่จะทำให้ SQLite เข้าถึงฐานข้อมูลบน S3 bucket ได้ เช่น: https://github.com/michalc/sqlite-s3-query
เดโมดูเจ๋งมาก แต่ผลลัพธ์ส่วนใหญ่มีคุณค่าค่อนข้างต่ำ เพราะมันคำนวณเงาจากด้านบนของเรือนยอดไม้ ไม่ใช่จาก พื้นดิน ดังนั้นแม้แต่ในป่าทึบก็ยังดูเหมือนมีแสงแดดตอนเช้า
ถึงอย่างนั้น มันก็น่าจะมีประโยชน์มากสำหรับหลายกรณี เช่น ขอบป่าหรือพืชพรรณในเมือง สำหรับกรณีใช้งานแบบนั้น แผนที่ไทล์อาจเล็กลงได้มาก และอาจดึงข้อมูล LiDAR มาแล้วแปลงเฉพาะตอนที่ต้องใช้ก็ได้
น่าจะเอาไปแปลงเป็นฐานข้อมูล SQLite แล้วให้บริการเป็นไฟล์สแตติกที่ต้นทุนต่ำกว่ามากไม่ได้หรือ?
https://news.ycombinator.com/item?id=27016630
range request ของ HTTP คือกลไกมหัศจรรย์หลัก แต่ส่วนนั้นก็ถือว่า “แก้ปัญหาแล้ว” อยู่แล้ว
นี่น่าจะใกล้เคียงกับแนวทางที่เป็น “มาตรฐานอุตสาหกรรม” ในปัจจุบัน แต่สำหรับนักพัฒนาตัวเล็กๆ อย่างผมก็ยังมีข้อเสียอยู่
อย่างแรก ต้องรัน tile server แยกต่างหากที่รับคำขอไทล์แล้วแปลงภายในเป็นคำขอ SQL หรือคำขอ mbtile ผมไม่ค่อยชอบเพิ่มชิ้นส่วนที่ต้องดูแลให้ระบบ
อย่างที่สอง ต้องประมวลผล GeoTIFF ทั้งหมดที่มีขนาดเกิน 10TB และยังเพิ่มขึ้นเรื่อยๆ ให้เป็น mbtiles ซึ่งมีทั้งต้นทุนการคำนวณและเวลาที่ใช้จริงสูงมาก
อย่างที่สาม mbtiles ที่ได้อย่างดีที่สุดก็มีขนาดพอๆ กับ GeoTIFF ต้นฉบับ และแย่หน่อยก็อาจใหญ่กว่ามาก หมายถึงได้คำขอที่เร็วขึ้น แต่ค่าโฮสต์และค่าโอนถ่ายข้อมูลสูงขึ้น ถ้าสนใจ มีบทความที่อธิบายเรื่องการปรับแต่งการบีบอัด GeoTIFF ได้ดีมาก: https://blog.cleverelephant.ca/2015/02/geotiff-compression-f...
Ted อาจมีมุมมองของตัวเอง แต่หลังจากที่ผมเพิ่งลงลึกในด้านนี้ตลอดหลายเดือนที่ผ่านมา นี่คือข้อสรุปที่ผมได้
ดี
ถ้าจะเล่าในมุมมองของคนรุ่นเก่าที่เคยทำงานด้านเทคโนโลยีภูมิสารสนเทศ ก็มีเรื่องที่เกี่ยวข้องอยู่บ้างและอาจจะน่าเบื่อเล็กน้อย นับตั้งแต่ช่วงทศวรรษ 2000 เป็นต้นมา หน่วยงานปกครองท้องถิ่นเริ่มว่าจ้าง การสำรวจทางอากาศด้วย LiDAR ในระดับเขตหรือบางส่วนของเขต และยิ่งไปกว่านั้นก็เริ่มมีแนวโน้มจะเปิดเผยข้อมูลดิจิทัลที่ได้ให้สาธารณชนเข้าถึง
ตั้งแต่กว่า 10 ปีก่อนแล้ว วิศวกรในภาคเอกชนก็ได้รับชุดข้อมูล LiDAR ครอบคลุมทั้งเมืองในปริมาณมาก และนำไปใช้เป็นประจำกับงานวิเคราะห์ แผนที่ และแบบร่างขนาดเล็ก
นโยบายการแบ่งปันข้อมูลของรัฐบาลท้องถิ่นแตกต่างกันมากในแต่ละพื้นที่ และก็น่าจะยังเป็นเช่นนั้นอยู่ในปัจจุบัน แต่บางครั้งข้อมูล LiDAR ก็ถูกส่งมอบมาในรูปหลายเลเยอร์ เช่น “ภูมิประเทศผิวดิน”, “อาคาร”, “เรือนยอดไม้” ซึ่งเป็นผลลัพธ์ที่ผู้ปฏิบัติการ LiDAR เก็บข้อมูลและคำนวณไว้ตั้งแต่แรกด้วยความถี่หลายแบบ
เจ้าหน้าที่เทคนิคในสำนักงานจะค้นหาและดำเนินขั้นตอนเพื่อปรับข้อมูลให้ตรงตามคำขอ โดยทั่วไปจะใช้ซอฟต์แวร์เชิงพาณิชย์และรูทีนต่าง ๆ เพื่อสร้างผลลัพธ์ขนาดเล็ก และบริการวิเคราะห์ แสงแดด/เงา กับการวิเคราะห์ทัศนวิสัยซึ่งคล้ายกับที่พูดถึงในที่นี้มาก ก็มีการว่าจ้างกันอยู่แล้วในยุคนั้น
ความพยายามระยะแรกในการรวม LiDAR ของเรือนยอดไม้เข้าไปในงานระดับย่านขนาดเล็กเริ่มซึมเข้าสู่ภาคเอกชน แต่ก็ยังเป็นเรื่องใหม่และพบไม่บ่อย การได้เห็นว่าตอนนี้งานลักษณะนี้ทำกันในสเกลใหญ่ถือเป็นเรื่องน่าชื่นใจ
สำหรับการให้บริการข้อมูลขนาดใหญ่ทางออนไลน์ ฉันแทบไม่มีประสบการณ์แบบไดโนเสาร์ของตัวเองในเรื่องนี้เลย แต่การจัดการกับชุดข้อมูลภูมิสารสนเทศดิบขนาดใหญ่กว่านั้นเป็นโจทย์หลักของวงการนี้มาโดยตลอด ท้ายที่สุดแล้ว งานทั้งหมดก็ลงเอยที่การแปลหรือย่อข้อมูลจากแหล่งเหล่านั้นให้ออกมาเป็นผลลัพธ์ที่มีประสิทธิภาพ เข้าใจง่าย และโฟกัสตรงตามวัตถุประสงค์
ในความหมายนั้น สิ่งที่ให้แรงขับเคลื่อนจริง ๆ แก่การทำให้นวัตกรรมแบบนี้ใช้งานได้จริงในวงกว้างก็คือด้านวิทยาการคอมพิวเตอร์ และให้เจาะจงกว่านั้นคือด้าน วิทยาศาสตร์ข้อมูล