ESRIC: Add write (CreateCopy()) support

[HusamMohammad]

What does this PR do?

Added write support for the ESRIC driver through the CreateCopy() pattern. The writer only supports writing the zipped .tpkx cache with JSON metadata, not the exploded directory cache characterized by the XML metadata conf.xml.

What are related issues/pull requests?

N/A

AI tool usage

• AI (Claude Code) supported my development of this PR. See our policy about AI tool use. Use of AI tools must be indicated.

Tasklist

• Make sure code is correctly formatted (cf pre-commit configuration)
• Add test case(s)
• Add documentation
• Updated Python API documentation (swig/include/python/docs/)
• Review
• Adjust for comments
• All CI builds and checks have passed

Environment

Provide environment details, if relevant:

• OS: Windows 11
• Compiler: MSVC 14.44 (Visual Studio 2022 Professional)

[rouault]

CC @lucianpls
I'm personnally on diet related to AI based contributions

[HusamMohammad]

Hi @lucianpls , any update on this?

[lucianpls]

@HusamMohammad

Hi,

To be honest, I don't see the need for this. Adding write for only TPKX format would be very confusing. Even if regular cache could be made writable, I don't really want to have to answer questions or maintain that kind of code in gdal.

The esri tile cache format is supposed to be a mostly read format that scales to really large sizes since the individual pieces can be worked on independently while being large enough to be more efficient that single tiles. The TPKX is only a transfer mechanism for a cache, which has problems when it gets large enough.
I added the standard cache reading because it was easy, not much code, and there is imagery in this format. TPKX reading was added later, being just a slight change of the metadata and organization, skipping the "unzip" part and dealing with the JSON vs XML metadata differences. The bundled cache format itself is somewhat flexible within esri, not telling where it will go next.

I prefer a separate toolchain, having the capability to create individual bundles and pack later, it would be higher performance, more useful and flexible. Similar to the gdal2tiles script. Pieces exist, like my own MaBaker that creates bundles using gdal python bindings. Adding a python "tpkx" python packer to that would be easy, if having TPKX is the ultimate goal.

[lucianpls]

I believe that esri has no intention of supporting tpkx as a generic raster format either.