Offline Managed Area Size Limit

Question

Hi,

According to https://enterprise.arcgis.com/en/portal/latest/use/take-maps-offline.htm, it appears that there's a 2.5GB size limit for offline map areas in ArcGIS 11.2

However, this size limitation was not mentioned in 11.1,11.0 and 10.9.1 and I was wondering if previous versions had a size limit at all or was this recently introduced in 11.2.

In addition to that, does the size limit only applies to the entire offline area package or individual feature layers/rasters.

I'm struggling to recall but I felt like I've packaged managed offline areas with sizes that exceed the 2.5GB limit.

tiztrain · Answer

We noticed similar in AGOL. Any offline packages above 1GB are suseptible to fail, they might work but they might not. So we have always recommended to keep our packages under this limitation.

AGOL funtionality are usually in line with the xy.x.0 versions and I have noticed that a 2.2GB size worked consistently so I was wondering if this had changed. Thanks for confirming this.

WengNg · Answer

Earlier Enterprises may not have had a hard limit specified in the documentation but there has been a lot of discussion on issues packaging data. There's a good chance that's why these hard limit recommendations eventually came to be.

I'm on 10.9.1 and I'm having issues packaging offline areas due to the size of the packages. Since discovering the size limit in the 11.2 documentation, I wondered if the hard limit had always existed but not specifically mentioned.

I'm surprised you haven't had a bad time doing this. It can take ages for fieldworkers to download.

You can create up to 16 offline map areas per web map. I'd recommend creating multiple offline areas, as optimized (small) as possible, instead of a single behemoth. I'd look to the 11.1 or latest size limit recommendations as a good guide - under 1gb is better.

I discovered that my map already had 16 offline map areas of various sizes (up to 3GB in size) which led me to question how the size limit was enforced. Then, I realised that when the offline map areas were created, they were very likely to be under 2GB in size initially.

As the size of some of the feature services grew, the data in the offline managed grew as well through the 'update' process. The 'Update' process appears to ignore size limits which is how I ended up with packages >2GB in size.

As soon as I try to recreate the exact same 'area', the packaging will fail because of the size limit above.

It does introduce a lot of issues in maintaining these offline areas because you could not knowingly be maintaining a perfectly working offline area that has exceeded the size limit but suddenly could not be recreated again due to the size limit and the result is a broken offline map area.

It does look like this limit can be configured according to :

https://support.esri.com/en-us/bug/unable-to-create-an-offline-area-for-a-large-data-size-bug-000157485

ChristopherCounsell · Answer

However, this size limitation was not mentioned in 11.1,11.0 and 10.9.1 and I was wondering if previous versions had a size limit at all or was this recently introduced in 11.2.

11.1 had a size limit of 1gb.

Earlier Enterprises may not have had a hard limit specified in the documentation but there has been a lot of discussion on issues packaging data. There's a good chance that's why these hard limit recommendations eventually came to be.

In addition to that, does the size limit only applies to the entire offline area package or individual feature layers/rasters.

Entire package. They recommend excluding attachments to decrease package size. It's generally the tile layers + large extent + high level of detail, or attachments, that contribute the most to package size.

I'm struggling to recall but I felt like I've packaged managed offline areas with a sizes that exceed the 2.5GB limit.

I'm surprised you haven't had a bad time doing this. It can take ages for fieldworkers to download.

You can create up to 16 offline map areas per web map. I'd recommend creating multiple offline areas, as optimized (small) as possible, instead of a single behemoth. I'd look to the 11.1 or latest size limit recommendations as a good guide - under 1gb is better.