[fdo-internals] Dropping off PSC

Tue Nov 2 15:38:46 EDT 2010

Hi Haris, 

The way I understand the OGR RFC, the new functions will replace the old ones, so you can use the ones with the int64 signature only. Here is a quote from the RFC:

"Furthermore, the new interfaces will internally support setting/getting integer fields, and the integer field methods will support getting/setting 64bit integer fields so that one case can be used for both field types where convenient."

So OGR remains easy to use.

Traian

> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
> Sent: Tuesday, November 02, 2010 3:04 PM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] Dropping off PSC
> 
> Hi Traian,
> 
> Hope I am not taking away to much from this thread title but wanted to
> answer to Traian,
> 
> On the other hand , you could be writing application in which size of
> the integer is important.
> >From system having 3 integers types into system having only one is
> very simple path (one single function), while otherwise is not
> possible.
> 
> By the way, I would expect that ogr after and if introducing int64
> will also end up with having two different functions.
> 
> Regarding shp provider, as I understood you, it is question of shp
> provider not fdo.
> 
> Haris
> 
> On Tue, Nov 2, 2010 at 3:49 PM, Traian Stanev
> <traian.stanev at autodesk.com> wrote:
> >> -----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 AM
> >> 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)
> >
> > The profusion of data types is one of the weak features of FDO from
> user standpoint, where user is defined as  application programmer who
> uses FDO (like me), and is what makes OGR look really attractive
> comparatively speaking.
> >
> > There are numerous places in code I've written where I have to do a
> massive switch on the data type, only to end up with either an int64 or
> a double in the end. It's a pain.
> >
> > There is no use for the API itself to provide all the integer data
> types as separate accessor functions, when it can have a single
> GetInt64/SetInt64 and internally enforce whatever width the underlying
> data store wants. In both cases the error would be some kind of FDO
> exception eventually, but in the unified one at least there is a single
> function that the programmer has to call, not have switch statements on
> data type every step of the way.
> >
> > There is also the strange Decimal data type, which you have to get as
> Double from FDO anyway, even in cases where it has 0 decimal places
> (i.e. is actually an integer). This has caused me headaches with the
> SHP provider for example, where all integer properties are decimals and
> you therefore have to treat them as "Double" (people might remember
> that labels based on integers in MapGuide would come out as
> "1234.000000000"). This is handled correctly in OGR, where they come as
> either real or integer, depending on the decimal places.
> >
> >
> > Traian
> >
> >
> >
> >>
> >> > 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
> >
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals