[fdo-internals] Dropping off PSC

[Leaf Li]

It seems there is no objection to this approach. Ok. I will clean up my changes to MITAB and send it to you for review later so that you can merge it into MITAB trunk.

By the way, do you know the address of MITAB SVN depot. I just know GDAL/OGR SVN depot contains it. 

Thanks,
Leaf Li

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Daniel Morissette
Sent: Wednesday, November 03, 2010 10:46 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Dropping off PSC

Traian Stanev wrote:
>> I got one idea. What about implementing MapInfo Provider without any 
>> touch on OGR API?
> 
> Wouldn't that then be a universal OGR API provider? Or do you mean that you will dynamic_cast the OGRLayer to something from the mitab headers and use specific mitab functionality?
> 

I think what he meant was to go through the MITAB C++ classes instead of through the generic OGR classes, and keep all extensions in the MITAB classes instead of trying to extend the OGR classes.

For instance, MITAB implements a TABFeature which is derived from OGRFeature and handles MapInfo-specific stuff, and then special classes such as TABPoint, TABRegion, etc. are derived from TABFeature. When used from OGR these are all OGRFeature's, but when used through the MITAB API they give you access to all the MapInfo specific stuff.

... and to answer Leaf's question: Yes, I think it would be easier/simpler to keep all MapInfo specific stuff in MITAB classes, and to base the FDO provider directly on the MITAB classes instead of on the generic OGR classes. It is exactly for that purpose that we maintain MITAB as a separate library (i.e. there are other vendors who use it this way as well).

Daniel
--
Daniel Morissette
http://www.mapgears.com/
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals