क्या स्पैटियालाइट वास्तव में धीमी है?

9

SpatiaLite में मेरे पास एक हजार बहुभुज हैं। मैं एक "स्पर्श" क्वेरी करने की कोशिश कर रहा हूं:

select map1.* from map1,map2
where touches(map1."Geometry",map2."Geometry")

और वाह, क्या यह धीमी है!

हालांकि, अगर मैं इसे मैप 1 में एक पार्सल के लिए बस करने के लिए कहता हूं, तो यह वास्तव में तेजी से चलता है।

select map1.* from map1,map2
where touches(map1."Geometry",map2."Geometry")
and map1."ROWID" = 753

मुझे उम्मीद है कि पहली क्वेरी धीमी चलेगी, लेकिन यह आश्चर्यजनक रूप से धीमी है। यह SQLServer, Manifold GIS और PostGIS में बहुत तेज चलता है। क्या स्पैटियालाइट सिर्फ वास्तव में अक्षम है?

spatialite

— AJL
स्रोत

9

स्थानिक की गति पर कुछ परीक्षणों के लिए यहां देखें - यह एक बड़े डेटासेट पर ST_Intersects ऑपरेशन के लिए 200 गुना गति वृद्धि का सुझाव देता है यदि आप अनुक्रमित का उपयोग करते हैं!

— सिमबंगु

इस लिंक Fezter के लिए धन्यवाद। उस उदाहरण के साथ एकमात्र समस्या यह थी कि उन्हें एक बाउंडिंग बॉक्स को शामिल करने के लिए अतिरिक्त SQL कोड लिखना था (और, उसे लिफाफे को खिलाने के लिए मजबूर करना पड़ा)। यह अच्छा होगा यदि स्थानिक का अगला संस्करण बस स्थानिक अनुक्रम का उपयोग करेगा जो पहले से ही वहां हैं।

— अंजल

Gis.stackexchange.com पर आपका स्वागत है! इस साइट के लिए प्रारूप का अर्थ है कि पोस्ट किए गए उत्तर मूल प्रश्न के उत्तर होने चाहिए। किसी उत्तर या टिप्पणी का जवाब देते समय इसे टिप्पणी करना सबसे अच्छा है।

— शॉन

16

नहीं, SpatiaLite इतना धीमा नहीं है, आपको बस एक स्थानिक सूचकांक का उपयोग करने की आवश्यकता है। SQLite डिज़ाइन में सीमाओं के कारण, किसी क्वेरी में स्थानिक इंडेक्स का उपयोग करना उतना अदृश्य नहीं है जितना कि PostGIS में है।

यहाँ SpatiaLite रसोई की किताब से संशोधित एक उदाहरण है http://www.gaia-gis.it/spatialite-3.0.0-BETA/spatialite-cookbook/html/neighbours.html

अपने बहुभुज डेटा सेट पर एक स्थानिक सूचकांक बनाने के बाद

    SELECT map1.*
      FROM map1, map2
     WHERE ST_Touches(map1.geometry, map2.geometry)
       AND map2.ROWID IN (
           SELECT pkid
             FROM idx_map1_geometry
            WHERE pkid MATCH RTreeIntersects(
                  MbrMinX(map1.geometry),
                  MbrMinY(map1.geometry),
                  MbrMaxX(map1.geometry),
                  MbrMaxY(map1.geometry)));

— DavidF
स्रोत

डेविडएफ: आपके उत्तर के लिए धन्यवाद। यह निश्चित रूप से चीजों को गति देगा। यह बहुत बुरा है कि स्थानिक संचालन स्पष्ट रूप से स्थानिक सूचकांक का उपयोग नहीं करते हैं। हालाँकि, मुझे लगता है कि अंतिम और क्लॉज को किसी एक प्रश्न पर किसी भी समस्या से निपटा जा सकता है। क्या आपको लगता है कि स्थानिक एक दिन स्थानिक सूचकांक का समर्थन करेंगे?

मेरी समझ यह है कि समस्या SQLite की वास्तुकला में अंतर्निहित है। आप निश्चित रूप से SpatiaLite Google समूह पर अधिक प्रश्नों के साथ पोस्ट कर सकते हैं। groups.google.com/forum/?fromgroups#!forum/spatialite-users

— DavidF

ध्यान दें कि Spatialite के नवीनतम संस्करण एक आभासी स्थानिक सूचकांक को लागू करते हैं, और उपरोक्त सिंटैक्स अब काम नहीं करता है। खंड के रूप में rewriten किया जाएगा कहां कहां map2.ROWID (SpatialIndex से चयन ROWID कहां f_table_name = 'map1' और search_frame = map1.geometry) में

— rudivonstaden

4

एरिक वेस्ट्रा की पुस्तक 'पायथन जियोस्पेशियल डेवलपमेंट' पृष्ठ 188 में दिखाया गया है कि कम से कम स्पैटियलिट के लिए CONTAINS ऑपरेशन के लिए, शायद, सुपरसाइडली, MySQL और PostGIS की तुलना में तेजी से भाग सकते हैं - यदि इसमें शामिल स्थानिक अनुक्रमण प्रक्रिया का पालन किया जाता है।

— जॉन स्टीडमैन
स्रोत

"आश्चर्यजनक रूप से" नहीं, क्योंकि साधारण प्रश्न SQLite में लगभग 2 · 3 सेंटीमीटर तेज चलते हैं, जैसे कि वे MySQL InnoDB इंजन में करते हैं।

— माइकल लियोन

3

मैंने कुछ समय पहले इस बारे में एक ब्लॉग लिखा था। Http://www.frogmouth.net/blog/?p=23 देखें

मीका ने इस विषय पर एक दिलचस्प ब्लॉग भी लिखा ।

— BradHards
स्रोत