<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I'm not sure that I have time to do a
full integration with GDAL. But I did continue my previous line of
work far enough that I now have a decent program for extracting
the raster data into GeoTIFFs. It's available at: <a
href="https://github.com/r-barnes/ArcRasterRescue">https://github.com/r-barnes/ArcRasterRescue</a><br>
<br>
It seems each raster is associated with five gdbtables. From these
the program makes a best effort to obtain a CRS WKT and
geotransform. It also determines the data type and performs endian
conversion. Decompression is still limited to LZ77 and
uncompressed formats.<br>
<br>
Best regards,<br>
Richard<br>
<br>
On 08/21/2016 05:17 AM, James Ramm wrote:<br>
</div>
<blockquote
cite="mid:CAEW=KS5SPf4T4OD=y=tbn5tN3PTKt8_THnaT7D2G7aiUZ-eMUA@mail.gmail.com"
type="cite">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
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true" href="http://www.spatialys.com"
target="_blank">http://www.spatialys.com</a><br>
______________________________<wbr>_________________<br>
gdal-dev mailing list<br>
<a moz-do-not-send="true" href="javascript:;"
onclick="_e(event, 'cvml', 'gdal-dev@lists.osgeo.org')">gdal-dev@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/gdal-dev"
target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/gdal-dev</a></blockquote>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>