[gdal-dev] Reading multipatch textures from FileGeoDataBase using GDAL

[Even Rouault]

Le vendredi 22 mai 2015 11:50:26, sameer.sheikh at wetransform.to a écrit :
> Hello Even,
> 
> Thank you for your suggestion, I have looked at ogr/ogrpgeogeometry.cpp
> file and I would like to point out the challenges that I am facing: 1. As
> far as I could understand it, the texture information has not been passed
> to the function which creates OGR representation from multipatch.

In the FileGDB driver, OGRCreateFromShapeBin() is called with the full 
geometry blob, including vertex coordinates, and hopefully followed by texture 
coordinates + material descriptions, which are currently ignored.

In the OpenFileGDB driver, as far as I remember, OGRCreateFromShapeBin() 
couldn't be directly called since the on-disk representation isn't directly 
the extended shapefile blob, although it is very close, and I didn't want to 
build an extended shapefile blob to be as fast as possible. So the parsing is 
done in more elementary steps and OGRCreateFromMultiPatchPart() is called. But 
I'd think that there are bytes currently ignored after the vertex information 
with the texture coords + materials. In case textures/materials are detected, 
you could also take a "slow" path and build the extended shapefile blob and 
pass it to OGRCreateFromShapeBin() to avoid code duplication.

> 2.
> OGRrepresentation doesn't include a place to write images to, so that
> would need to be extended. I would welcome and appreciate some guidance
> regarding what could be changed to make it work.

That's the tough part. We don't even have a proper geometry type for 
multipatch. Currently this is modelled as a OGRMultiPolygon but this isn't 
really correct, and should be a POLYHEDRALSURFACE as of ISO SQL MM-Part 3, 
becoming a new OGR geometry type OGRPolyhedralSurface.
Then you could imagine also add the texture and material info on it, although 
that seems to be really a ESRI specific stuff not present in standards, so not 
obvious if that would be appropriate to expose in the OGR abstraction.

Another idea would be to expose the geometry blob as a OFTBinary field of the 
feature (likely conditionnized by a open option so that folks that don't want 
it don't have issues with this binary field), and then parse it completely on 
your side, or have dedicated functions&structures in OGR to parse it and 
retrieve texture & material info.


> Also, I  would like to
> mention that we are happy to contribute any improvements back. Regards,
> Sameer Sheikh
> On Thu, May 21, 2015 at 07:05 PM, Even Rouault  wrote:
> Sameer,
> 
> I am using GDAL (Java binding) API in my application to read from file
> geodatabase. I am trying to read multipatch geometry and textures of a
> Building. I could read features, Geometry, relationship information etc.
> from file geodatabase, but unable to read multipatch textures. Could
> anybody suggest me approach to read textures from filegeodatabase?
> 
> There's no way with OGR currently. You should be able to get the vertex
> information from the multipatch, but textures are ignored for now. It's not
> directly obvious however how they could be modelled in OGR.
> 
> If you're also a C/C++ programmer, you could look at the Extended Shapefile
> specification provided with the FileGDB SDK, and hack into
> ogr/ogrpgeogeometry.cpp to enhance the multipatch decoder to decode
> textures.
> 
> Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com