Yes, there is some form 2d index - each raster has a corresponding .col_index.atx, .row_index.atx, _.blk_key_index.atx and .band_index.atx files. I've not looke at how they work together so far.<div><br></div><div><br><br>On Sunday, 21 August 2016, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Richard,<br>
<br>
> I saw a posting from July<br>
> <<a href="https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044761.html" target="_blank">https://lists.osgeo.org/<wbr>pipermail/gdal-dev/2016-July/<wbr>044761.html</a>> about<br>
> work towards deciphering the Arc File Geodatabase Raster format.<br>
><br>
> Inspired, I did some work today and successfully extracted a raster from<br>
> a geodatabase.<br>
><br>
> Using Even Rouault's /dump_gdbtable/ as a starting point, I decompressed<br>
> the raster blobs using zlib, as suggested in the posting.<br>
><br>
> For my raster, this gave 128x128 big-endian 32-bit floating-point values<br>
> with a trailer of about 512 bytes.<br>
><br>
> Assembling these 128x128 tiles using the col_nbr and row_nbr fields<br>
> resulted in the raster coming out.<br>
><br>
> I've uploaded my fork, along with appropriate input data and a command<br>
> to run it all (see README.md) to <a href="https://github.com/r-barnes/dump_gdbtable" target="_blank">https://github.com/r-barnes/<wbr>dump_gdbtable</a>.<br>
><br>
> What remains is to link metadata (block size, band_width, band_height)<br>
> to the raster so the output can be sized appropriately, the data type<br>
> deduced automatically, and projections saved. This is probably just a<br>
> matter of linking the appropriate rows from some of the lower-numbered<br>
> gdbtables with the files containing the raster data. It might also be<br>
> nice to determine whether zlib is always being used, but I assume an<br>
> error could be thrown if an unexpected compression format is encountered.<br>
<br>
One can expect other compression formats according to :<br>
<a href="http://desktop.arcgis.com/en/arcmap/10.3/manage-data/raster-and-images/raster-compression.htm" target="_blank">http://desktop.arcgis.com/en/<wbr>arcmap/10.3/manage-data/<wbr>raster-and-images/raster-<wbr>compression.htm</a><br>
None of them seem to be particularly difficult given what GDAL supports ("raw" RLE and "raw" LZW<br>
would probably require a bit more work as there is no direct drivers that support them, although they<br>
are codecs of some other GDAL drivers like TIFF, and so could be perhaps wrapped on the fly in a in-memory TIFF)<br>
<br>
What they call LZ77 must be the ZLib one (according to<br>
<a href="https://en.wikipedia.org/wiki/Zlib" target="_blank">https://en.wikipedia.org/wiki/<wbr>Zlib</a> ZLib's DEFLATE is a modified LZ77)<br>
<br>
><br>
> I'm interested in seeing GDAL include the ability to translate Arc File<br>
> Geodatabase Rasters into other (less proprietary) formats.<br>
> What is a good way to move forward with that?<br>
<br>
"A bit" of coding !<br>
ogr/ogrsf_frmts/openfilegdb/<wbr>filegdbtable.cpp should probably be extended to offer<br>
the low level access to the rasters.<br>
And ogropenfilegdbdatasource.cpp to implement the GDAL Raster API using the above.<br>
Regarding efficiency of random reading of tiles, I'm wondering if they have some form of 2D (row, column)<br>
indexing or perhaps 3D (row, column, pyramid_level). For the vector part, I only addressed the case<br>
of 1D indexes.<br>
As a fallback sequential reading through the records could still be used, perhaps with some tricks to read only the start<br>
of the records to get the (row, column, pyramid_level) values, if located at the beginning of it,<br>
and not the raster data if not needed.<br>
<br>
Even<br>
<br>
><br>
> Best regards,<br>
> Richard Barnes<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><br>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'gdal-dev@lists.osgeo.org')">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a></blockquote></div>