[gdal-dev] OT: COM Interfaces of the OGR
paul at t...
Fri Aug 31 21:50:09 EDT 2001
Thanks for the reply.
> Technically, the sfcom-dev mailing list described on the OGR page is
> to cover OGR issues as well as SFCOM/OLEDB specific issues. However, it
> that most people just use the GDAL list because of the close association
> OGR and GDAL.
As you already know, I am a member of the sfcom-dev mailing list too.
However, it seems
to be focus on the OLEDB providers and not knowing which list is best to
address the issue,
I decided to mark it Off-Topic!
> In part I haven't fought this because I have a long term dream of
> OGR and GDAL more closely. Shared driver mechanism, metadata handling and
> forth. However, I have no schedule for such an overhaul.
I have being trying to really see the line of coupling but it seems to be
very narrow. It is
mostly the use of projections.
Well, in the formats directory of the GDAL you might find shapelib too. Is
this really being
used in the GDAL?
I am not particularly worried about the attempt to integrate them, since in
my work I will
actually separate them anyway :-(
I will be working on a COM server version of the Proj4, with the ability to
C++ class wrappers too. This will be used by the GDAL module and the OGR
These are all Windows specifics, and I will make it available to anyone
interested, or post it
to the file section of the two mailing lists.
> The SFCOM interfaces are dramatically incomplete. I basically abandoned
> that work when it became clear that for most intents and purposes the
> OLEDB portion of the Simple Features for COM/OLEDB was all that was very
I agree with you. However, VB/Delphi clients will not kick it. The COM
will be the option for such tools. For C++ clients, most may prefer the C++
> Are you working in a COM environment where you would like to have the
> proper SFCOM interfaces implemented? I would be happy to cooperate on
> such an effort, but you would likely be stuck doing the bulk of the work
> since I don't have any supporting projects or compelling interest. It
> would be nice to have from a completeness point of view.
Yes, I am working on a commercial application and wish to have to SFCOM
I am in complete control of the project here and will make the sources to
available to anyone interested.
Cooperations in terms of design is all that is needed, you do not have to
the implementations-I am being paid to do that anyway :-)
> Assuming you know COM better than I (not hard!) you might find it better
> to start from a clean implementation, discarding what I have done so far.
> But it should be possible to build an implementation closely on the
> OGRGeometry classes. They where intended to map pretty closely onto what
> is in the spec.
I do not see how the knowing better comes in here. I have already taken a
look at your
work there and it will serve at the base of any such efforts, even a clean
> Just let me know if you need CVS commit access.
Thanks, not now. I am working for a company, and we have some naming rules-I
myself :-) After successful implementations, I will repack the OGR features,
comply to the
current naming rules and post them and update them whenever there is any
More information about the Gdal-dev