ThinkGeo.com    |     Documentation    |     Premium Support

Display Performance with SQL Server 2008 Spatial

#1

I have been looking into how to "boost" display performance with data storage in SQL Server 2008 spatial format. Using SQL Server Management Studio (recent expensive queries) I noticed when Map Suite fetches data it uses the STIntersect. I have read several documents concerning SQL Server and they recommend using the STFilter instead of Intersect when the exact number of records returned in not critical. 


I would be curious to know if Map Suite has tested the Filter method to improve drawing performance. I also did some reading that at the next release (SQL Server 2011), the filter time is even faster given some new indexing that will be put in place.


Go here and download the Word document, about SQL Server 2011:


sqlcat.com/whitepapers/archive/2010/11/09/new-spatial-features-in-sql-server-code-named-denali-community-technology-preview-1.aspx


 


See blogs.msdn.com/b/isaac/archive/2008/04/08/more-on-the-multi-level-grid.aspx about Filter vs Intersect


Q: What is the difference between STIntersects and Filter?


A: If there isn't an index, they do exactly the same thing.  This can  happen on the client, or on the server if you haven't defined an index  (or if the index isn't chosen for some reason).  When there is an index  involved, Filter will not do any secondary filtering.  I.e., it  is only guaranteed to return a superset of the results an STIntersects  predicate will return: it may return extras. This is useful for applications that are simply displaying results,  are not sensitive to some extras, and want to avoid the cost of the  secondary filter.  If you need precise results, use STIntersects.


Thanks.


-John



#2

John, 
  
 We are doing some researches on this point, if there are any updates I will let you know, 
  
 Thanks, 
  
 Scott,

#3

Have have run 2 queries on a building footprint polygons for Lancaster, PA that I wanted to share with you. We're in Lancaster so it makes sense since a lot of testing is done with this data set. The Filter option does seems faster, but is it fast enough to make a difference (more testing would need to be done).


Here are the queries:


SELECT GEOM.STAsBinary() as GEOM,gid FROM Buildings_All WHERE (geometry::STGeomFromText('POLYGON((-8495809 4844773, -8493839 4844773, -8493839 4846154, -8495809 4846154, -8495809 4844773 ))',3395).STIntersects(GEOM)=1);



SELECT GEOM.STAsBinary() as GEOM,gid FROM Buildings_All WHERE (geometry::STGeomFromText('POLYGON((-8495809 4844773, -8493839 4844773, -8493839 4846154, -8495809 4846154, -8495809 4844773))',3395).Filter(GEOM)=1);

 


Please note the method of using a "POLYGON" was from another app we tested and they showed us how they were running the query. I see Map Suite us using (geometry::STGeomFromWKB(@geometry,3395).STIntersects(GEOM)=1) instead. 


Of course as you know, you have to balance getting more records back with the speed it takes to render the data. If I enlarge the area above, I get 11,000 records with Intersect and 12,000 with Filter.


But seem to execute very fast.


Thanks for looking into this. I'm curious what you determine.


-John



#4

John, 



Thanks for the further information about the query mode of MsSql2008Layer, as you said, the STIntersects query can return the precise results than the Filter query mode, but the Filter query mode has higher performance than the STIntersects. So we have to balance between them, first I think most of the users want the precise results, second it is the performance issue. If we consider the precise results first we have to sacrifice some performances when querying. But your question is still a good suggestion for us,  if you think support the Filter query mode of MsSql2008Layer would be a good addition to Map Suite, please feel free to suggest it on our enhancement tracker at:  


helpdesk.thinkgeo.com/EnhancementTracker


and see if the Map Suite community will give it any votes. This is a new feature and we should consider most of the users' requirements, we will track the enhancement tracker if it needs to be added an new API for that. 



Any more questions please let me know, 



Thanks, 



Scott,