We have evaluated the World Map Kit, and decided to deploy it. However, we did a lot of work to make it meet our needs. I thought it might be helpful to to others to describe what we did, as well as provide suggestions to ThinkGeo about potential enhancements to the solution.
All of our customers are in North America, and most of them operate in only a few counties within a single state. As such, the deployment size of the WorldMapKit in its native form was a showstopper for us. To address this, we wanted to break the full install into a "Core" install that is required for all users, and then individual state installs that can be selectively installed by each customer.
Here are things that we did:
- We wrote a simple program that scanned the original USA folder for the tlka, lpt, etc sub folders.
- Within those, we created a subfolder for every distinct state-specific 2-character prefix that we found on the files, and moved all state-specific files into separate state-specific subfolders.
- While doing that, we also built index files for each individual shapefile so we could move away from the MultiShapefileFeatureLayer construct.
- We wrote out a little script for our installation package, so that when completed, we had a pre-made install script for every state-specific dataset.
- We edited the provided renderer class to do away with all of the MultiShapefileFeatureLayer constructs and replace with ShapefileFeatureLayer.
- We changed all of the "RenderSymbolLayer(new ShapefileFeatureLayer(...)) and RenderLabelLayer(...) methods to accept the name of the shapefile, and instantiate the layer within the method. In this way, if the shapefile is not there, it can be easily trapped, skipped the rendering, and drive on with other files. We have many shapefiles we did not want to distribute. This is a change that ThinkGeo should make in future releases.
- We created a RenderLayerDelegate so that we could pass a rendering function to a more generic shapefile processing class:
private delegate void RenderLayerDelegate(FeatureLayer layer); - In the locations that found all state-specific shapefiles and added them to a MultiShapefileFeatureLayer, we now call a generic multi-file processing function with a filename pattern and the rendering or labelling delegate.
- We make the original RenderClass derive from the abstract Layer class, making this effectively a multi-layer layer. We added a DrawCore method to draw the Feature and Label layers that were created from all of the rendering functions.
With this done, we have a single class that is Layer. We instantiate it with the data folder in the constructor, and everything else is encapsulated. We just add it to our map as a single layer, and it "just works". The class will find any data that has been installed, and survive any missing data. We've tested with 5 states loaded at one time, and we don't see any penalty for using multiple ShapefileFeatureLayers vs a single MultipleShapefileFeatureLayer.
If you find any of this useful, drop me a note for more info. But, ThinkGeo guys, you might want to consider some of this as part of any new release you make. I sure did like that all of the complex rendering classes were written. Out of the box, the maps look quite good. We have only done some zoom-level tweaking.