ThinkGeo.com    |     Documentation    |     Premium Support

How to deal with large stringy shapes?

#1

Hi people,


My name is Welton and I've been evaluating MapSuite for a couple of weeks and I've been experiencing some issues related to performance. The problem is related to a specific table layer in PostgreSQL which is filled with streets from all over the country (Brazil). For you to have an idea, we got over 3.5 million lines in that table. I dumped the table content into a shape file and instructed MapSuite to use it instead the PostgreSQL table, but it's even worse. The reason is that the shape file dumped is sized of 1.5 GBytes what results too many disk accesses. What I did was split that shape in many smaller shape files and I created a tiled index over these shapes. This process gave me a new very small shape file (shp, dbf and shx) which just points to those shape files resulted from the splitting process. I recompiled my source to point to that small shape file which theoretically should lead to the rest of the shape files and I got no street lines in my map. The question is: is it possible to use Tiled Shape Files with MapSuite? If not, how do you people can advise me to deal with large layers?


Thanks in advance! Any ideas you got will be appreciated!


Welton

 



#2

Welton,


I think what you need is to generate the idx / ids file for the shape.  Idx / ids files are an Rtree based spatial index which can greatly speed up your querying. For example, you want to show the records within a small area, which let's say include 100 lines. Without the index, the component needs to check every of the 3.5 million lines to see if it is within the view area. While with the idx file, we only need dozens of check before we find the results. 


You can use the Map Suite Explorer to generate the idx file, which can be found in "Start" -> "All Programs" -> "ThinkGeo"->"Map Suite Web Full Edition 3.0 (Beta)".  You can open the shape file with it first and there will be a box showed up suggesting you to generate the idx file. However we found some flaws that for huge shape files, it will consume huge memory to generate the idx/ids. We have just solved that in the latest Service Edition, which will be released today. So if the huge shape file doesn’t work well with the existing Map Suite Explorer, please download the latest service edition (the evaluation edition is for free, make sure you download the right one: 3.0.98) later today and use the Map Suite Explorer there. It will generate the right idx / ids files for you.


This enhancement will also be included in the next Beta of Web Edition, which will be released around middle of next month.


Any queries please let us know.


Ben



#3

Hi Ben, 
  
 Thanks for the answer! I’ve build the index using Map Suite Explorer and the performance has improved a lot. I had already a .shx file and thought that would be the index, but I guess I was wrong the Map Suite needs another kind of index. Are .idx and .idl a sort of proprietary pattern than only MapSuite can understand? I’ve built another shapefile index using another tool borrowed from Mapserver which gave a index file with an extension .qix. I told MapSuite to use it but it didn’t get that format. As you may already know, .qix is a QuadTree index and has shown to yield a lot performance when we deal with geographical information. 
  
 What about tiled shape files? Does MapSuite support them or is there any plans to do so? 
  
 I’ll get on with the tests, put some more memory in my server and measure the performance. I’ll let you guys know if I find anything that could be wrong. 
  
 Best regards

#4

Welton, 
  
 The .idx and .ids files are our proprietary format similar to ESRI’s sbn and sbx, which themselves are proprietary so we had to roll our own. It essentially is an R-Tree based index file for spatial indexing. We so not support the QTree index format as it is inferior to R-Tree’s querying performance.  The .shx file is not for spatial indexing exactly; it is just for quickly getting a shape from a record number. It cannot help a lot if you do some query like getting all records inside a rectangle and is especially slow for large datasets. 
  
 Splitting your shape files will not buy you very much.  The R-Tree index was designed for finding small groups of record within huge data sets. 
  
 Thanks for bring us that idea though and any queries please let us know. 
  
 Ben. 


#5

You're write Ben. We've splited our shapes ourselves and it didn't buy us any speed up. 


I did what you said and that made a huge difference. In fact I'm still running the app in a weak server and it's far from having a satisfactory performance, though I notice a lot of improvement. I'll get a good machine soon and run the same application on it and post the results here.


Thanks for the tips.


Welton


 



#6

It’s my pleasure, Welton. Hope you have a great application with Map Suite! 
  
 Ben.