|
|
Home » Developing U++ » UppHub » GDAL/OGR library 'import' now in sandbox
|
|
Re: GDAL/OGR library 'import' now in sandbox [message #45579 is a reply to message #45578] |
Mon, 07 December 2015 21:48 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
I can't just now read the source, but just out of curiosity, how did you handle the TIFF dependency which gets satisfied twice (once in gdal/geotiff and second in plugin/tiff)? This is actually one thing that I could not solve immediately in a clean way... (The linker complained about double definitions of TIFF functions when I tried the sandbox version briefly.)
Best regards,
Tom
|
|
|
Re: GDAL/OGR library 'import' now in sandbox [message #45582 is a reply to message #45578] |
Wed, 09 December 2015 12:55 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
After tinkering around for a while, I managed to get both GDAL and OGR side working beautifully for all the drivers I needed. The key here was to call the appropriate driver registration functions separately instead of relying on the default GDALAllRegister(), which I guess remains unconfigured.
Thank you very much for this excellent addition to bazaar!
Best regards,
Tom
|
|
|
|
|
|
Re: GDAL/OGR library 'import' now in sandbox [message #45676 is a reply to message #45584] |
Mon, 21 December 2015 16:01 |
Tom1
Messages: 1212 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
I have initially tried to connect to your GDAL encapsulation for reading raster maps.
I'm missing at least access to:
Band::GetColorTable();
Band::GetColorTable()->GetColorEntryCount();
Band::GetColorTable()->GetColorEntry();
Band::GetColorTable()->GetPaletteInterpretation();
and also a way to read the data block directly in the native buffer format. Some rasters are really big and in one byte per pixel format. If these are readily converted to int or double, it is easy to run out of memory on 32 bit systems.
--
Before we proceed with this any further, may I ask why the encapsulation? While rewriting my calls to match Gdal:: instead of original GDAL interface, I found similar complexity but with partially unfamiliar interface. I could better understand this encapsulation if we had e.g. a GeoImage:: class and even a TiledGeoImage:: class, which were automatically loaded from raster files using Gdal:: and representing the raster content as an Image:: that has georeferencing data directly available. (Of course the 32 bits per pixel RGBA data storage of Image makes this less than optimal in memory for large files, but a very nice solution in principle.) Maybe storing the raster data in original pixel depth plus a palette in a GeoImage:: and then adding Image generation for selected area with desired transform would be a better solution.
Best regards,
Tom
|
|
|
Goto Forum:
Current Time: Sat May 11 13:07:24 CEST 2024
Total time taken to generate the page: 0.03362 seconds
|
|
|