[Gdal-dev] Re: Rendering optimization [Re: Looking for huge vector dataset]

[Mateusz Loskot]

Ari Jolma wrote:
> Mateusz Loskot kirjoitti:
>> Personally, I'm not sure if a data access layer is the right place
>> to do such optimization, quite rendering-specific.
> 
> Yes, rendering specific, but rendering, or geovisualization or
> mapping, is a (or the) major application area for geodata. Also, to
> be efficient, such optimization would probably need to be implemented
> near to the actual data access procedure.

Ari,

There are many applications and situations required exact data.
So, if we would want to have rendering optimization included in OGR,
we would need to provide doubled interface:
- non-optimized, for all those who need to analyse exact data
- optimized, using various simplification methods, etc.

I'm not sure there is any room for that.

> This is the biggest headache I have in my geospatial GUI, I think.
> Has anybody seen rendering big vector data sets been satisfactorily
> solved in any desktop GIS?

It is a complex task, indeed.
I've seen two approaches and the very base idea is not directly
related to rendering, but to data management:

1. load the whole geometry data into memory, into simple structures
(arrays) - this is similar to how Manifold works

2. suck data from the disk (datasource like file/database) on every read
(draw) - this is memory efficient but limited by speed of data medium
access. This approach is used by GDAL, as well as old ArcView 3.x.

BTW, have you tried to implement simplifications out of OGR?

> Often implementers show the incremental rendering so that users don't
> get bored while waiting, but it still is slow.

Yes, that's another possible improvement, also multi-threaded rendering
if workstations have more than 1 CPU is a good idea.

>> I agree it would be worth to include this kind of functionality to
>> the OGR geometry model, but as an option.
>> 
> 
> A natural place for it would be a method, for example 
> OGRLayer::SetSpatialApproximationFilter that would be similar as the 
> method OGRLayer::SetSpatialFilter, i.e., it would be used in 
> ResetReading, GetNextFeature loop. I haven't thought much about what 
> kind of class a SpatialApproximationFilter would be, though.

Ari, I believe there is a room for such experiments,
and we have the 'spike' in GDAL repository.
Although, I can only be a tester or help in conceptual work, but I won't
be able to do any serious coding for this during coming months.

Anyway, I'm not very convinced to the idea, but I'd be happy to see it
working and get some measurements ;-)

> Hm, this could be a very nice project for a student...

Great idea.

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net