Open hrishereforyou opened 6 years ago
I received this same error, but I believe for a different reason. Inside my tpk was a bundle with a .bundle.done filetype per the logging message:
INFO:tpkutils:Reading bundle: v101/Layers/_alllayers/L00/R0000C0000.bundle INFO:tpkutils:Reading bundle: v101/Layers/_alllayers/L00/R0000C0000.bundle.done
then in the Traceback while trying to process the bundle.done bundle:
....
File "C:\Software\Anaconda3\envs\JLPy35\lib\site-packages\tpkutils__init__.py", line 201, in
I wonder why the tile package contained a 'bundle.done' file, and if so, would it be OK to ignore it? (Since there was a bundle file with the same root, but no .done suffix)
I used Esri GP tool 'Create Map Tile Package' from ArcToolbox to create the tpk.
@jeff3780 would you mind trying to create your TPK file again, and inspect it to see if the new one also contains the *.bundle.done
file? It might be that the bundle was not fully created due to some error, and this may be masking a potential issue.
Also - what version of ArcGIS did you use?
@brendan-ward I am using the latest 10.7 version of ArcGIS. I went ahead and reran the tpk as you suggested, and this time, no *.bundle.done were generated into the tpk. I used the same mxd, extent, and tiling scheme as I had before when it did generate those .done bundles.
When I previously generated the tpk (with the .done bundles), I was watching the folder structure being created using Windows Explorer, so that I could see what was going on behind the scenes. I wonder if that corrupted the process somehow? This time, I just set the GP tool running, and left everything alone until it was completed.
If my actions did cause the corruption, then I guess a word to the wise to not mess with things as the GP tool is running. On the other hand, it might be worth a quick scan of bundle names just to make sure, and to avoid the exception. I could probably put that in a try/catch, and warn the user to regen if caught.
With all that being said, nice job on this code! I think it is going to be very useful for an upcoming project that I am working on. Thanks for your efforts, and for the reference to other resources describing the formats involved.
@jeff3780 I'm glad this is useful for you, and also glad that it is holding up in ArcGIS 10.7 (several versions newer than I've tested).
A PR to address this issue, as you've described, would be very welcome.
bug init.py line 201 r_off, c_off = [int(x, 16) for x in root.lstrip('R').split('C')]
Range of hex is 0-F so could contain C. possible fix r_off, c_off = [int(x, 16) for x in [root[1:5], root[6:10]]]