Folks,
I've created a ticket with this issue and attached the patch trying to
handle both issues.
http://trac.osgeo.org/gdal/ticket/3224
According to the changes the gdal default block cache implementation
have been replaced with a hashtable based approach for the WMS driver,
and the raster
Hi Even,
Yes, I thought it was a bit complicated issue. I would also support
replacing the array of pointers with a hashtable to eliminate the
unnecessary memory requirement. I've been looking at the code and
found a hashset implementation in CPL which could probably be utilized
here, however
Tamas Szekeres wrote:
Hi Even,
Yes, I thought it was a bit complicated issue. I would also support
replacing the array of pointers with a hashtable to eliminate the
unnecessary memory requirement. I've been looking at the code and
found a hashset implementation in CPL which could probably be
Selon Tamas Szekeres szeker...@gmail.com:
Hi Even,
Yes, I thought it was a bit complicated issue. I would also support
replacing the array of pointers with a hashtable to eliminate the
unnecessary memory requirement. I've been looking at the code and
found a hashset implementation in CPL
2009/11/13 Even Rouault even.roua...@mines-paris.org:
But I'm surprised you claim it doesn't support auto-grow and cannot store
items
with the same hash value : those both features are already implemented and
unless you prove me wrong, they work ;-)
Even,
Yes, you're right! By looking
Jumping in here, and I may be misunderstanding, but I don't see how we
would have greater than 2 gigapixel images in the foreseeable future.
Doing the math: if we represent the entire earth as a single image, each
pixel would be 2 cm at the equator, and the whole image would be 6291456
TB in size
2009/11/13 Seth Price s...@pricepages.org:
Jumping in here, and I may be misunderstanding, but I don't see how we
would have greater than 2 gigapixel images in the foreseeable future.
Doing the math: if we represent the entire earth as a single image, each
pixel would be 2 cm at the equator,
