Fastest way from ExecuteQuery to GetBoundingBox

ThinkGeo UI for Web WebForms
1

 Hello ThinkGeo People,


 


Here is a good question...I think.  What is the quickest way from a sql search to getting the bounding box on a feature.  I am doing this currently on a large database so it is fast to do the SQL search but slow to return the Feature.  I am sure there is a faster way to do this but not totally sure what that is.  Here is an example of what I am doing:



 DataTable dataTable = worldLayer.QueryTools.ExecuteQuery("Select * From");
            worldLayer.Close();
            List<DataRow> list = dataTable.AsEnumerable().ToList();
            var staticOverlay = (LayerOverlay)Map1.CustomOverlays["StaticOverlay"];
            var spatialQueryResultLayer = (InMemoryFeatureLayer)staticOverlay.Layers["SpatialQueryResultLayer"];
            worldLayer.FeatureSource.Open();
            Collection<Feature> spatialQueryResults = worldLayer.QueryTools.GetFeaturesByColumnValue("LABEL", list.ElementAt(0).ItemArray.ElementAt(4).ToString());
            worldLayer.FeatureSource.Close();

            spatialQueryResultLayer.InternalFeatures.Clear();
            spatialQueryResultLayer.Open();
            foreach (Feature feature in spatialQueryResults)
            {
                spatialQueryResultLayer.InternalFeatures.Add(feature.Id, feature);
            }
            spatialQueryResultLayer.Close();
            staticOverlay.Redraw();

            if (spatialQueryResultLayer.InternalFeatures.Count > 0)
            {
                spatialQueryResultLayer.Open();
                Map1.CurrentExtent = spatialQueryResultLayer.GetBoundingBox();
                spatialQueryResultLayer.Close();

 


 


Thanks in advance for your input!


Kev



2

Hi Kevin, 
  
 That’s an interest question. 
  
 I try to test your code but it looks the dataTable.AsEnumerable().ToList(); met error here. So could you did a test in your environment, add some stopwatch to make sure which line takes most time when you operate a big shape file. I think the result should be helpful to locate the problem. 
  
 Regards, 
  
 Don

3

Hey Don,  
  
 The code all runs fine on my end…? 
  
 The portion of code that is very slow is this: 
 
worldLayer.FeatureSource.Open();
            Collection<Feature> spatialQueryResults = worldLayer.QueryTools.GetFeaturesByColumnValue("LABEL",list.ElementAt(0).ItemArray.ElementAt(4).ToString());
            worldLayer.FeatureSource.Close();
  
 This bit of code grabs the feature after you know which feature to grab…   
  
 What I would like to know is how to get the bounding box from a sql search?  What is the quickest method to do this?  Is it the method I presented above?   
  
 Thanks, 
 Kev

4

Hi Kevin, 
  
 Thanks for your response, I don’t know why but the .ToList(); and .ElementAt(0). cannot pass compilation in my vs2010. 
  
 Your worldLayer should be a InmemoryFeatureLayer and it really will so slow when did spatial query even than you get all items from shape file? 
  
 Because we don’t have a better way to get boundxing box from sql search, so I want to make sure that, maybe we can find the reason and optimize it so that imporve the speed. 
  
 Regards, 
  
 Don

5

Thanks for the response Don. 
  
 But let me return to the initial question: "What is the quickest way from a sql search ----> to retrieving the bounding box on a feature?" 
  


6

Hi Kevin, 
  
 How huge the feature number is in your layer? 
  
 I suggest you directly get all features then add them to InmemoryFeatureLayer, build index for this layer, then did all query works on it. I think that should more faster. 
  
 Regards, 
  
 Don

7

Hey, 
  
 I have been working with something similar.  2 things that seemed to speed things up for me: 
  
 Instead of pulling the static layer, which for me is my feature layer from Map1.StaticOverlays, I just redeclare a new ShapeFileFeatureLayer. 
  
 I found that GetFeaturesById is faster than GetFeaturesByColumnValue, and it allows you to grab multiple features at once.  I simply added the id as a column in my sql tables.  The id is the native primary key, and is faster, at least it was for me. 
  
 Eric 
  


8

Hello Eric, 
  
 We are really thanks for your advise and help. 
  
 Kevin, please let us know if you still troubled by this problem. 
  
 Regards, 
  
 Gary