ThinkGeo.com    |     Documentation    |     Premium Support

Questions in regards to WorldMapKit 2009

#1

We are planning to switch our base maps to WorldMapKit 2009 and I had a couple questions / issues that I am seeking answers for.


1.   From looking at the DVD that we have received, it seems that we are missing ??lkaA30.shp files from \USA\TLKA\?? from those directories.  Were those files omitted intentionally or is it a mistake? The demo code included with the WorldMapKit 2009 is referencing that information.


2.  .midx files are not there any more.  I saw a number of comments that mentioned that for 2009 version, ThinkGeo moved away from single .midx index files.  This actually present a number of performance issues for us.  We are using WorldMapKit to serve WMS tiles - so we need to render multiple images to display enough information for a single page.  In the previous version of WorldMapKit, the number of files was reasonable since street networks and such ended it up in a MultipleShapeFileFeatureLayer.  With the current version, individual files are added instead - to a total of 400+ files in the collection - that alone slows everything down when we need to render the information as we going through the layers one by one: the code currently looks similar to this:


             foreach (var geoLayer in layersToRender)


            {


                lock (geoLayer)


                {


                    geoLayer.Open();


                    gdiPlusGeoCanvas.BeginDrawing(nativeImage, parameter.BoundingBox, GeographyUnit.DecimalDegree);


                    geoLayer.Draw(gdiPlusGeoCanvas, labelsInAllLayers);


                    gdiPlusGeoCanvas.EndDrawing();


                    geoLayer.Close();


                }


            }


We have tried a number of approaches to get around this problem.  As it stands, MultipleShapeFileFeatureLayer would have still worked if it was not for the directory structure change - since individual street files moved into State specific subdirectories, there is no easy way to specify a collection to load.  Another approach is to use MultipleShapeFileFeatureLayer(string[] multipleShapeFiles, string[] multipleShapeFileIndexes) override; however this requires .midx files to be present.  I wrote a small program to generate the missing .midx files and used the later version of MultipleShapeFileFeatureLayer function and ended up with something that performs reasonably well (something comparable to WorldMapKit 2007 and way faster that WorldMapKit 2009). 


Can you comment on this case: are there plans to bring .midx files back?  


 



#2

I would suggest you contact directly support at support@thinkgeo.com to see what could have happened with your DVD and why some files seem to be missing. If you prefer you can call at 866.847.7510 x 111 . Thank you.

#3

Will do.  What about my second quesiton?



#4

Val, 
  
   One item 2 i see what you are having an issue with.  The reason we went away from one large midx file for the roads etc were that many users wanted to only support certain states and that is a little more cumbersome with midx.  With midx it is all in one file and all in one shot.  So that was the reasoning, to a solution I think the main issue is that since you have to loop through all of the states that is adding a bunch of extra read writes that we don’t necessarily want especially since 99% of the time we are only dealing with one or two states at that zoomed in level.  What I would propose we do is to create another small index file that has the bounding boxes of the states.  Before you do your looping we query that file to see what states we need to query.  In that way we can eliminate 99% of the other states and that makes your loop either just one step or a t a max a few steps and not 50.  This way we can keep the data partitioned to allow people to easily split it.  We can do a test to see if the state file exists for the state we want. 
  
 What do you think of this approach as somewhere in the middle? 
  
 David

#5

David,


that sounds like an option.  One question I have is whether the peformance of it would be any better than having .midx files present in each subdirectory for every file (that's what I ended up generating) and then using MultipleShapeFileFeatureLayer to load the .shp and .midx files together.  One advantage to the later method I can see is that I can use MapEngine to generate the tiles (I actually switched my code yesterday to look something like this).


var  map = new MapEngine;

foreach (var geoLayer in layerSet.LoadGeolayers())

                    map.StaticLayers.Add(geoLayer);


//Please note that map above is cached 




            lock (map)

            {

                map.CurrentExtent = parameter.BoundingBox;

                map.OpenAllLayers();

                geoImage = map.DrawStaticLayers(parameter.Width, parameter.Height, GeographyUnit.DecimalDegree);

                map.CloseAllLayers();


            }


For reference, here is a screenshot of my resulting layout of files with .midx files added



 



#6

Val, 
  
   I see for every tile you are closing all the map layers using the CloseAllLayers method .  I suggest you leave them open and the performance should go up.  No sense in closing them if you have the MapEngine cached, I mean if you want to cache then you need to leave the layers open.  You can call the open as if the layer is already open it will just check an internal flag and do nothing so it is safe.  I think if you do this your performance problem will go away even under the way we ship the code. 
  
 David

#7

I removed the calls to Close - but it seems that once I have .midx files in place, it really does not make that much difference in performance whether I call CloseAllLayers or not.

#8

Val, 
  
   Can you remove the midx files and try with the CloseAllLayers removed?  This way you can stay with stock data and still get good performance.  In this way we don’t need to change our data that we ship and the footprint will be smaller as well. 
  
 David

#9

Thank you for your suggestions.  I finally got some free time to test out your suggestions and was able to get the relatively good performance without the usage of .midx files (basically caching the layers and removing CloseAllLayers method)

#10

Val, Thanks for letting us know your status.I am glad seeing your progress and appreciate your sharing. 
  
 Any more questions just feel free to let me know. 
  
 Thanks. 
  
 Yale