dynamically unpacking an .mpk

[TalShapiro]

Hello,
I'm developing an application that should support .mpk as well as other (local) file types.
All the layers are presented in a tree and the user can control their visibility, Opacity, Min/Max resolution and change the tree structure/hierarchy.
For .mpk files I am required to "breakdown" the package and expose the inner layers like any other non-packed layer (and support the functionality mentioned above).
This could hopefully be achieved without unpacking the file to disk...

I was thinking about creating an "ArcGISLocalDynamicMapServiceLayer" for each internal layer in the package and hide all the other layers (setting Visibility to false). Then I could load each internal layer independently into the map.
I guess this should work, however, I'm concerned about the performance implications.
Few questions:
1) I will obviously need to initialize the layer and set the visibility before loading it into the map. Does initialization of a layer (in particular an ArcGISLocalDynamicMapServiceLayer) load the layers geographic data?
2) Does the Map control only loads the visible data (i.e., the visible internal layer)?
3) Does this idea even make sense?

Many thanks!
Tal

[MatthewBrown1]

Hi Tal,

What you are asking is achievable in a number of different ways, depending on how you create your MPK(s), how many layers you are using and whether you classify them as base map or operational layers, and if they are feature classes or rasters, etc.

If you include the data in the MPK, it will unzip everything to the local file system. You can also reference data, so the MPK only stores the MXD/MSD files. I have also seen some posts about adding rasters and shapefiles without an MPK.

Spinning up the map service(s) is going to affect performance as well. If the layer is referenced by the MPK, it will start a service for that layer regardless of whether you add it to the map or not. If this layer is not added to the map control or turned off, I don't think the app will request data for that layer. (You could use something like Fiddler to test this.)

Using tile packages and accelerated display are things that can help improve draw performance.

Do you need to perform editing in your app? LocalFeatureLayers can be resource hungry, especially if you are using a large number of features, but there are some methods to manage this.

I don't do rigorous performance benchmarking as part of my work, so I can't comment too much on the relative affects these have on performance.

There are also some videos that the team at ESRI have done (e.g. http://video.esri.com/watch/2321/implementng-analysis_comma_-editing_comma_-and-offline-applications...) that might be helpful.

A bit of a ramble, but I hope it helps.

[TalShapiro]

Thanks Mike.
I will execute some performance tests and publish my conclusions.