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

[L Pool]

Hi Jacob,

I agree with what Frank says here. If you're worried about rendering speed
then you shouldn't be rendering directly from the Vector File.

I don't even keep them in memory after reading them to a reduced structure
that only contains vertices (or the like) - some of these Vector Maps are
huge!.

I've written a viewer in OpenGL that utilizes the OGR library to capture
Vector Data. I use Display Lists of GL_LINE_STRIPs (GL_POLYGON are a bit
slower) to render each (OGR)Geometry, organized according to their Layers.

Also, I check whether a Geometry intersects with my viewing volume before
calling its Display List - this reduces overhead considerably - its not
necessary to draw things that are out of your field of view. And if a
Layer's Envelope is outside of your Viewing Volume you can avoid iterating
thru its (child) Geometries.

Currently I'm loading 400 MB Vector Files with Raster Maps to boot and my
application never goes below 50 fps on my Radeon 9600 Pro.

Ok. Now for something totally unrelated - this is a question for pretty much
anyone who can help me out with a little bit of knowledge on Geographic
Projections in GDAL.

I've written a few Geographic conversions for certain Projection
Algorithms - but the maths that I wrote them from does not have parameters
for "False Eastings" and "Fast Northings" which the OGRSpatialReference
class definitely has. E.g.

Albers Conic Equal Area:

OGRErr OGRSpatialReference::SetACEA  (  double    dfStdP1,
  double    dfStdP2,
  double    dfCenterLat,
  double    dfCenterLong,
  double    dfFalseEasting,
  double    dfFalseNorthing
 )

you have your Standard Parallels and the Center Lat/Long pair (which is all
I use in my projection algorithm) - but where do the False Easting and False
Northing params come from? I know what an Easting and a Northing is - I
don't know how it fits into the projection algorithm tho. Does it have to do
with your own Cartesian reference?

Very puzzled!

Louis.






-----Original Message-----
From: gdal-dev-admin at remotesensing.org
[mailto:gdal-dev-admin at remotesensing.org]On Behalf Of Frank Warmerdam
Sent: 19 May 2004 03:52
To: gdal-dev at remotesensing.org
Subject: Re: [Gdal-dev] Re: Re: how to extract data from OGR


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

_______________________________________________
Gdal-dev mailing list
Gdal-dev at remotesensing.org
http://remotesensing.org/mailman/listinfo/gdal-dev