Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » UppHub » GDAL/OGR library 'import' now in sandbox
GDAL/OGR library 'import' now in sandbox [message #45494] Mon, 23 November 2015 21:39 Go to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
svn://www.ultimatepp.org/upp/sandbox/se
Re: GDAL/OGR library 'import' now in sandbox [message #45578 is a reply to message #45494] Mon, 07 December 2015 14:37 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Moved to bazaar/plugin. Light encaplulation added (practically copied form plugin/geotiff)
Re: GDAL/OGR library 'import' now in sandbox [message #45579 is a reply to message #45578] Mon, 07 December 2015 21:48 Go to previous messageGo to next message
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 Go to previous messageGo to next message
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 #45583 is a reply to message #45579] Wed, 09 December 2015 16:29 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Mon, 07 December 2015 21:48
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


Well, I have solved in unclean way Smile A lot #defines to rename gdal tiff routines...
Re: GDAL/OGR library 'import' now in sandbox [message #45584 is a reply to message #45582] Wed, 09 December 2015 16:32 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Wed, 09 December 2015 12:55
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


Well, there is some light encapsulation provided, which should call all registres on Open.

Check bool Gdal::Open(const char *fn)

I would like to know whether encapsulation provided is usable...

Mirek
Re: GDAL/OGR library 'import' now in sandbox [message #45587 is a reply to message #45584] Thu, 10 December 2015 15:10 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi Mirek,

I did not try the encapsulation, since my code (since 2008) references GDAL directly. I just replaced the external GDAL library with the Upp GDAL plugin to get rid of the bloated DLL and to ease compilation of GDAL. (To be more specific, the executable grew by about 2 MB while I was able to drop the 7 MB DLL. Smile

--

It seems the encapsulation is for the raster part, while I also use the vector part (OGR). When I get some time, I could look at the raster encapsulation and test how it works.

The vector part (OGR) obviously needs the corresponding driver registrations. Encapsulation for OGR would be quite different.

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 Go to previous message
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
Previous Topic: Report Class with custom icon
Next Topic: New SplitterButton control added to Controls4U
Goto Forum:
  


Current Time: Thu Mar 28 15:32:33 CET 2024

Total time taken to generate the page: 0.01902 seconds