3

Is there a way to use Map Packaging so that multiple mxds draw data from the same geodatabase when unpacked? We've broken our project area into 14 divisions. Each division has it's own geodatabase and there are about 30 mxds per division drawing data from that geodatabase. I've been asked to give all our project data (over 400 mxds) to clients and I want to do that efficiently from a file storage standpoint?

In my limited experience with map packaging, it looks like it would create one geodatabase file for every MXD. If true, I'd have over 400 .MPK with each one having it's own geodatabase. Is there a way to reduce the redundancy in geodatabases since there are about 30 mxds pulling data from the same .gdb?

If file duplication and storage is a concern, would it be better to abandon map packages and provide the mxds and data using relative paths?

  • I suspect you also want to include layouts and such, but if you can skip that for some of them you should also consider using .lyr-files. I'm leaning towards it's easier to go with relative paths, but I'll leave the answering to someone with good arguments. MPK-files are supposed to be self-contained, that's their raison d'être, so I doubt you can create any synergies storage-wise between map packages. – Martin Aug 27 '15 at 13:02
4

A Map Package (mpk) will only hold 1 MXD, but could hold multiple GDBs. If your original MXD has 100 featureclasses from 5 different databases (multiple fGDB or SDE instances), the data that gets copied to the package will be held inside 5 GDBs named based on the original database. So to your point, you're sort of correct. Its more you'd have 400 MPKs if you had 400 MXDs.

If you want to cut down on the number of MPKs, you'll need to cut down the number of MXDs. You'd have to go through the process of merging MXDs into one (or just a few) master MXDs and packaging those. You could maybe use dataframes as an indicator of what was an MXD. When you package the master MXDs into an MPK, data inside is not duplicated. If a layer existed in multiple dataframe all pointing at the same source, you only get 1 copy of it in the MXD (unless it came from a different database...)

If you have ArcGIS Pro, you could make a PPKX (package project). You'd import all your MXDs into the project, then package the project itself. Of course your client would need ArcGIS Pro.

| improve this answer | |
  • While you're last suggestion looks promising, I'm working in ArcMAP v. 10.1. I'm also stuck with the 400+ mxds. – Bernie Aug 27 '15 at 15:26
  • 1
    I realize my comments above may not provide a "solution", hopefully it provides at least a starting point to help you chose a direction. You'll probably end up writing some script to help merge multiple MXDs OR create multiple packages. Based on what you want today and what you already have, theres no simple way to get to the end. – KHibma Aug 27 '15 at 16:06
0

Map packages are just zip files with a different extension. Use 7zip or whatever to unpack the package somewhere, delete the internal .gdb that hold the in-common data across all MXD, then repack the package.

When the MPK is delivered and opened the MXD will have broken layers; use the standard "Repair data sources" tools/methods to point to the shared in-common data GDB.

The "repair data sources" part can be scripted done before the projects are re-packed and delivered.

Command line example to remove all occurrencess of the shared data (common.gdb) from a map package and repack automatically (ref):

7z d -r repack-example.mpk common.gdb

Script examples for changing layer paths can be seen at Changing data source for all layers in MXD?

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.