[Gdal-dev] Re: Re: how to extract data from OGR

Frank Warmerdam warmerdam at pobox.com
Wed May 19 09:51:31 EDT 2004


Jacob Bensabat wrote:
> Hi and thanks for your message.
> I must say that I enjoy this discussion.
> 
> I understand that interfaces to OGR are created whenever there is a need to
> connect a software
> to OGR. The point is that when studying the code you have porvided, there is
> a need to
> call to many functions in order to get the information needed for
> rendering/drawing, which,
> if done in a context of windows drawing, may alter the efficiency of the
> drawing (I have not tried but I guess).

Jacob,

I don't see that traversing from a polygon down to a set of rings represeted
as linearrings will add much overhead.   The x and y accessors for the linestring
positions are already inlinable so there shouldn't be any call overhead for them.

In short, I don't think there is in appropriate levels of overhead here.  However,
for high performance rendering engines it may be desirable to keep data packed
in a way that is "ready to use" with native rendering engines.  For instance,
for OpenGL applications it may be desirable to convert geometries into callable
display lists.

> The question is whether there should be some methods within the OGR layers
> that allow fast strait access to the data (points, lines, polygons,
> attributes, patterns symbols and colors) instead of recursively looping
> inside each layer.
> then my question is if there is a reason for not having such kind of methods
> (GetData, GetColor, GetSymbol, ....)

What would GetData return?

Symbolization is a complex area.  The approach taken (via styling strings) is
relatively sophisticated but does not lend itself to something as simple as
GetColor() and GetSymbol() on a feature as a feature may use multiple symbols
(or none), and there may be several colors involved in drawing a feature.

I would add that OGR was intended to be based on the OpenGIS Simple Features
model for features and geometries and that is evident to some degree is the
nature of the geometry classes.  It wasn't written to be maximally efficient
though it makes some effort to make data compact, and access reasonably fast.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent




More information about the Gdal-dev mailing list