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

[Jacob Bensabat]

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).

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, ....)
thanks
jacob

----- Original Message ----- 
From: "Frank Warmerdam" <warmerdam at pobox.com>
Newsgroups: gmane.comp.gis.gdal.devel
Sent: Tuesday, May 18, 2004 3:10 PM
Subject: Re: Re: how to extract data from OGR


> Jacob Bensabat wrote:
> > Hi
> > I have now a conceptual question. I went over the file you have posted
> > and what I see is that you have defined other containers for
> > processing the data stored in the OGR layers.  What is the rationale for
> > that ?
> > Would it be justified to use directly OGR ? If not what is the reason ?
> > thanks
>
> Jacob,
>
> I assume you are referring to the mapogr.cpp code?  MapServer had it's own
> internal feature format before OGR support was introduced, so the reader
> converts to it's internal format.  I am not sure whether OGRFeature's
would
> have been an appropriate internal format for MapServer or not.
>
> There are applications that use the OGRFeature as the internal format, but
it
> more common to have some other application specific internal format and
convert
> to that during an import phase.
>
> I would add that even when different internal representations are used, it
is
> convenient if applications can use a similar "simple features" geometry
model
> unless there is a specific reason to do something different like CAD
packages
> requiring 3D solids and curves, or a topological GIS.
>
> 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