[fdo-internals] FDO RFC 54 is ready for review.

Leaf Li leaf.li at autodesk.com
Wed Oct 27 00:18:06 EDT 2010 

I agree that getting the MITAB changes reviewed and submitted back to the originating SVN depot sounds is a good idea. Actually it is my original idea when I tried to implement MapInfo Provider. However, I changed my idea later. The major reason is that MITAB is based on OGR model. Actually MITAB is just one of OGR driver. In order to make MapInfo FDO provider support more powerful, I have to extend OGR model. Some of changes are as follows.

1. We need to extend OGR geometry and data type. Currently OGR supports the following geometry types and data types only. However, MapInfo and FDO supports more. For example, both MapInfo and FDO support curve string, curve polygon, multiple curve polygon, Boolean, decimal, small integer data type. Adding supports for those new geometry type and data type isn't just to add some new enum values. It will result in lots of OGR API changes. Moreover, how to handle ORG drivers? 

typedef enum 
{
    wkbUnknown = 0,             /* non-standard */
    wkbPoint = 1,               /* rest are standard WKB type codes */
    wkbLineString = 2,
    wkbPolygon = 3,
    wkbMultiPoint = 4,
    wkbMultiLineString = 5,
    wkbMultiPolygon = 6,
    wkbGeometryCollection = 7,
    wkbNone = 100,              /* non-standard, for pure attribute records */
    wkbLinearRing = 101,        /* non-standard, just for createGeometry() */
    wkbPoint25D = 0x80000001,   /* 2.5D extensions as per 99-402 */
    wkbLineString25D = 0x80000002,
    wkbPolygon25D = 0x80000003,
    wkbMultiPoint25D = 0x80000004,
    wkbMultiLineString25D = 0x80000005,
    wkbMultiPolygon25D = 0x80000006,
    wkbGeometryCollection25D = 0x80000007
} OGRwkbGeometryType;


typedef enum 
{
  /** Simple 32bit integer */                   OFTInteger = 0,
  /** List of 32bit integers */                 OFTIntegerList = 1,
  /** Double Precision floating point */        OFTReal = 2,
  /** List of doubles */                        OFTRealList = 3,
  /** String of ASCII chars */                  OFTString = 4,
  /** Array of strings */                       OFTStringList = 5,
  /** deprecated */                             OFTWideString = 6,
  /** deprecated */                             OFTWideStringList = 7,
  /** Raw Binary data */                        OFTBinary = 8,
  /** Date */                                   OFTDate = 9,
  /** Time */                                   OFTTime = 10,
  /** Date and Time */                          OFTDateTime = 11,
                                                OFTMaxType = 11
} OGRFieldType;

2. Some minor change to OGR API. For example, I need to extend class OGRFeature so that it is possible to check whether it is a deleted feature.

class CPL_DLL OGRFeature
{    
  public:
    .....
    virtual GBool       IsRecordDeleted() { return m_bDeletedFlag; };
    virtual void        SetRecordDeleted(GBool bDeleted) { m_bDeletedFlag=bDeleted; };
    ....
}

There are some such kind of API changes. I can't remember all of them.

If MapInfo provider includes MITBA library directly, I can modify OGR interface freely and don't need to think about other OGR drivers. So finally I give up my original idea.

Hope my explanation helps.

Thanks,
Leaf Li


-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Tuesday, October 26, 2010 10:50 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] FDO RFC 54 is ready for review.

I agree that getting the MITAB changes reviewed and submitted back to the originating SVN depot sounds like a nice idea. It removes the need for a fork and opens up the maintenance of that code to a greater number of developers, testers, etc. 

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Tuesday, October 26, 2010 10:33 AM
To: 'FDO Internals Mail List'
Subject: RE: [fdo-internals] FDO RFC 54 is ready for review.


Hi Leaf,

The motivation behind the OGR provider was not to write another SHP provider. It was to support formats which do not have a dedicated FDO provider for whatever reason. So it is unfair to say that the OGR provider was written to be another SHP provider -- it is just a coincidence that OGR has SHP support (in some respects better than the native FDO provider, BTW).

In the RFC, you state that the OGR provider has certain limitations -- some of which are due to the MITAB driver, which you have forked and fixed. Doesn't it make more sense to contribute those fixes back to GDAL and automatically pick up the write support via the OGR provider? Sure, some fixes may be needed in the OGR provider, but they would be far less work than a whole new provider.

Instead, you plan to maintain a fork of MITAB and also a whole new provider -- more work for FDO maintainers. Also, GDAL, to which you owe the initial implementation of the MITAB driver loses, since you don't contribute your changes back.

Now, let's look at some of the claims in detail:

* thread safety -- if the underlying OGR driver is thread safe, then OGR is thread safe as well. So if you fixed MITAB driver can be used in a per-connection way, then this will also work with the OGR provider.

* extra data types -- which ones specifically?

* 64 bit -- OGR compiles on 64 bit in general (at least on Linux I have not had problems), what exactly is the problem there?



Traian


> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals- 
> bounces at lists.osgeo.org] On Behalf Of Leaf Li
> Sent: Tuesday, October 26, 2010 9:12 AM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] FDO RFC 54 is ready for review.
> 
> It is an interesting question. May I use one question to answer your 
> question?
> 
> ORG provider already provide read/write access to SHP file. Why do we 
> create a new SHP provider?
> 
> I guess you ask this question because MapInfo provider is based on 
> MITAB and MITAB is based on OGR model. So I think I need to explain 
> how MapInfo is based on MITAB in details.
> 
> Although MITAB is based on OGR, it is an standalone library and we can 
> modify MITAB and ORG freely in the same time. For example, ORG has 
> limited data types and geometry types. I can extend OGR model so that 
> more data types and geometry types are avaiable in MITAB library. The 
> OGR extend is limited in MITAB library only.
> 
> However, it has great impact if I am going to extend OGR library 
> directly. All of OGR driver need to be updated.
> 
> Actually data types and geometry types is only one of reasons. For 
> example, we want MapInfo provider supports 64bit and per-connection 
> thread safty. If we modify OGR to support those features, it is huge 
> work because there are lots of OGR drivers.
> 
> Thanks,
> Leaf Li
> 
> ________________________________________
> From: fdo-internals-bounces at lists.osgeo.org [fdo-internals- 
> bounces at lists.osgeo.org] on behalf of Frank Warmerdam (External)
> Sent: Tuesday, October 26, 2010 12:52 PM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] FDO RFC 54 is ready for review.
> 
> Leaf Li wrote:
> > All,
> >
> >
> >
> > FDO RFC 54 (FDO Provider for MapInfo .TAB and .MIF/.MID Files) is
> ready
> > for review. Can you review it?
> >
> > http://trac.osgeo.org/fdo/wiki/FDORfc54
> 
> Leaf,
> 
> I guess I just don't understand why you would invest all this effort 
> in a mapinfo specific provider, when it shouldn't be noticably harder 
> to make the OGR provider do the same things and it would be helpful 
> with lots of formats.
> 
> 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
> 
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-
> internals_______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals

More information about the fdo-internals mailing list