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

[Traian Stanev]

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