मैं अपने सहज ज्ञान युक्त "अंगूठे के नियमों" का उपयोग करता हूं ... यह तेजी से निर्णय के लिए उपयोगी है,
आपके DATABASE के बारे में : यदि सुविधाएँ और / या स्थानिक विश्लेषण महाद्वीपीय-पैमाने के हैं , और सटीक (गंभीर अनुप्रयोगों) की आवश्यकता है तो भूगोल का उपयोग करें । अन्य ज्यामिति का उपयोग करें: जब सभी डेटाबेस समान ( शहर-स्केल ) क्षेत्र के बारे में हों, या आपको परिशुद्धता की आवश्यकता नहीं है, आदि आपको केवल ज्यामिति की आवश्यकता है। @Underdark
के सुझाव व्याख्यान में समान नियम देखें ।
निष्पादन / सटीक संतुलन के संदर्भ में आपकी आवश्यकताओं के बारे में : ज्यामिति तेज है; यदि आपको प्रदर्शन की आवश्यकता है और भूगोल का उपयोग करने के लिए सोचें, तो पहले अपने बेंचमार्क करें।
प्रमुख धारणाएँ
इस पृष्ठ पर, हम कुछ कुंजी-शब्द और कुछ अवधारणाओं पर ध्यान केंद्रित करते हैं: सटीक , प्रदर्शन और लचीलापन / उपयोग की वस्तु जैसी कुछ ।
जैसा कि दूसरों द्वारा याद किया जाता है, स्टोर और गणना के लिए अंतर, ज्यामिति में भूगोल और विमान क्षेत्र में उपयोग होता है:
- क्षेत्र (भूगोल) बेहतर, अधिक सटीक है। देखें लॉस एंजिल्स / पेरिस उदाहरण ।
- भूगोल का विकास: जैसा कि @DavidF कहता है, "भूगोल प्रकार हाल ही में जोड़ा गया था, इसलिए कम कार्य समर्थित / कार्यान्वित किए जाते हैं"।
शायद वर्ष 2020 पर सभी जीआईएस डेटाबेस एक ही मानक एसआरआईडी / ईपीएसजी (आजकल 4326 कोड के बराबर, WGS84 के लिए) सेट किए जाएंगे। आज भूगोल प्रदर्शन और कार्यात्मक सीमाओं के कारण एक डिफ़ॉल्ट विकल्प नहीं है।
विचार-विमर्श
मेरी राय में यह "सर्वोत्तम प्रथाओं" का सवाल है, न कि एक गहरी तकनीकी / सैद्धांतिक समस्या का।
शुद्धता
अपने डेटा पर त्रुटि का अनुमान लगाने के बाद, अपने परीक्षण करें और परिणामों की तुलना करें: भूगोल के साथ सटीक लाभ डेटा की त्रुटि से अधिक है? ST_Distance समारोह (साथ मैक्स और एवीजी एग्रीगेटर्स ) प्रयोग इस तरह का में मुख्य संदर्भ है।
प्रदर्शन
~ 100 किमी 2 (व्यास ~ 11 किमी) के एक शहरी क्षेत्र में बेंचमार्क के उदाहरण , सभी को एक ज्यामिति के रूप में संग्रहीत किया जाता है, एक प्लानर यूटीएम समन्वय प्रणाली में। नोट: अक्सर उपयोग किए जाने वाले ज्यामिति / भूगोल रूपांतरण के साथ शुरू - अक्सर क्योंकि कुछ फ़ंक्शन मौजूद नहीं हैं और कुछ अन्य, जैसे ST_Buffer और ST_Intersection, आंतरिक रूप से रूपांतरण करते हैं।
बेंच # 1: एक तालिका ~ 87000 बहुभुज शहरी लॉट का प्रतिनिधित्व करती है, प्रत्येक पाली के साथ (औसत) ~ 13 अंक
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS
SELECT gid, the_geom FROM urbanlots; ROLLBACK;
-- time 2080 ms ~ 2.0 s
BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS
SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog
FROM urbanlots; ROLLBACK;
-- time 12374 ms ~ 12.4 s ~ 6 * geometry.
इसलिए, भूगोल_ समय = 6 * ज्यामिति_टाइम।
बेंच # 2: शहरी ब्लॉक का प्रतिनिधित्व करने वाली ~ 3500 पॉलीगोन के साथ एक तालिका, प्रत्येक के साथ पाली (avg) ~ 50 अंक: 0.6s बनाम 2.7 s, भूगोल_ समय = 4.5 * ज्यामिति_टाइम।
बेंच # 3: ~ 10000 लाइनें शहरी सड़कों का प्रतिनिधित्व करती हैं, प्रत्येक ~ 5 अंक के साथ। ~ 0.87s बनाम ~ 0.36s, भूगोल_टाइम = 2.4 * ज्यामिति_टाइम।
पीठ # 2 पर जाएं, तालिकाओं का निर्माण करें और प्रश्न करें,
EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom)
FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
-- time 182 ms ~ 0.2 s
EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog)
FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
-- time 58657 ms ~ 59 s ~ 300*geometry
-- curioselly for only distances, geography=4*geometry
निष्कर्ष: छोटे कार्यों और अच्छे हार्डवेयर के लिए, समय "स्वीकार्य-समान समय" में परिवर्तित हो जाता है, लेकिन बड़े कार्यों के लिए, विचार करने के लिए प्रदर्शन रेटिंग होती है।
सुविधा / कमोडिटी
बेंचमार्क पर मैं दिन-प्रतिदिन का काम करता हूं, अंकों की संख्या की जांच करता हूं (द्वारा ST_NPoints) ... यह ऑपरेशन का एक उदाहरण है जो भूगोल के लिए मौजूद नहीं है, कलाकारों की जरूरत है। "भूगोल / ज्योमेट्री कास्ट" प्रोग्रामर, मास्टर्स आदि के लिए एक कष्टप्रद कार्य है।
SQL और PL / pgSQL फ़ंक्शंस के पुस्तकालयों का पुन: उपयोग करते समय, भूगोल को अनुकूलन की आवश्यकता होती है। और, यदि आप कोड का अनुकूलन करना चाहते हैं, या बहुत से मध्यस्थ रूपांतरणों के साथ सटीक समस्याओं से बचना चाहते हैं, तो भूगोल के साथ बिल्ड-इन फ़ंक्शन का एक पूरा सेट की अनुपस्थिति एक और समस्या है। भूगोल के लिए कार्यक्रम, एक आसान काम नहीं है।
प्रोसेस-ओनली, डेटा इंटरचेंज इत्यादि।
गैर-सामान्य मांग के लिए, मैप्सएवर जैसे किसी गहन उपयोगकर्ता के साथ, जब आपका एकमात्र (PostGIS) कार्य इनपुट डेटा को संसाधित करना और किसी भी समय (जैसे या घंटों) संसाधित डेटा पर वापस लौटना है, तो अंगूठे का नियम है "भूगोल का उपयोग करें यदि आप आराम से हो! ” (ऊपर "लचीलापन / कमोडिटी" देखें)। यदि नहीं, तो सामान्य नियम देखें।
नोट: बेशक, यदि आपका (गैर-सामान्य) कार्य केवल PostGIS से लेकर Mapserver तक के डेटा को दिखाता है, जिसमें आपके इनपुट डेटा के समान (ज्यामिति या भूगोल) को संरक्षित करने के लिए कोई प्रक्रिया की आवश्यकता नहीं है, तो यह बेहतर निर्णय है।
मेरा मानना है कि डेटा केंद्रीकरण एक अन्य कार्य है जहां भूगोल बेहतर है: संदर्भ में जहां इनपुट प्रारूपों और संदर्भ प्रणालियों की विविधता सामान्य है, एक मानक का उपयोग, जैसे कि भूगोल द्वारा लागू किया गया, लाभकारी है ... कॉन्फ़िगरेशन पर कन्वेंशन है एक अच्छा सिद्धांत है जब केंद्रीकरण और डेटा इंटरचेंज व्यापार पर ध्यान केंद्रित करते हैं (Google मानचित्र देखें!)।