[fdo-internals] Dropping off PSC

[Leaf Li]

I got one idea. What about implementing MapInfo Provider without any touch on OGR API?

1. For field type, OGRFieldDefn already define method GetWidth and GetPrecision. As long as MITAB returns the correct width and precision, we can let MapInfo FDO provider to distinguish different data types according to their width and precision. 
2. For geometric type, Iet's remove support for curve line, curve polygon, multiple curve polygon.
3. If we really want to add any new API, let do it in MITAB class level.

Then we don't need to go through OGR/GDAL RFC process and be able to focu on MITAB and MapInfo FDO Provider. What do you think?

Thanks,
Leaf Li

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam (External)
Sent: Tuesday, November 02, 2010 8:55 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] Dropping off PSC

Leaf Li wrote:
> I will try to summarize all of my changes to OGR and write one GDAL 
> RFC document for your review. Actually those are exactly MITAB issues 
> that I met.
> 
> 1.  As for field type, I have a little different opinions. I found you 
> already write one GDAL RFC to address 64bit integer.
> http://trac.osgeo.org/gdal/wiki/rfc31_ogr_64
> 
> Why do you think it is a problem to add int16, float, decimal?

Leaf,

I am proposing adding int64 because a 32bit integer cannot represent large integer values.  I find it most unfortunate that I need to add such a type, and have resisted it for years, but there is no other way to actually preserve the field values.

 > If the field
> type is int16, GDAL expose it as int32. It must there are some issue 
> to update filed value with one integer value larger than maximum value 
> of int16. For me, I think the major issue is efforts. I don't know 
> what are exactly your concerns. However, providing some sort of 
> additional hints mechanisms around attribute fields is a good idea.

My concern is complication of the API, increase in the number of cases applications and driver code must try to deal with.  I feel the role of a glue layer, like OGR, is to provide a normalized view of data not too complicated by details of the storage format.  There is, of course, a tension between fine grained control and simplicity.  FDO has clearly taken the approach that there is no grain too fine to provide FDO mechanisms to handle.  OGR aims for simplicity over fine grained control.

(IMHO)

> 4. My biggest concerns is I have to handle all of OGR drivers once I 
> any changes to OGR API. It isn't one trivial task. If I am not busy in 
> next several months, I can finish it using my spare time. Otherwise, I 
> have to check whether Autodesk will provide funding for it.

Well, I guess it just feels like a job half done if MITAB is forked into a distinct FDO provider and then orphaned without a resourced effort to re-integrate the changes upstream.  I respect how much you have accomplished on your own time, but I can't ask you to spend lots more time struggling through the GDAL and MITAB RFC/contribution process.
Hopefully Autodesk or some other client will see the provider as strategic and support further work on it.

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