[fdo-internals] Dropping off PSC

[Traian Stanev]

> 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?

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: Wednesday, November 03, 2010 5:09 AM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] Dropping off PSC
> 
> 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
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals