[fdo-internals] Dropping off PSC

Wed Nov 3 11:44:22 EDT 2010

Well, I don't think this needs an RFC, but the impact of such a change on existing applications in somewhat unclear. Will they have to alter their implementations to account for the new behavior? Would any workarounds currently in place have to be removed?

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: Wednesday, November 03, 2010 11:32 AM
To: 'FDO Internals Mail List'
Subject: RE: [fdo-internals] Dropping off PSC

Hi Dan,

I would love for this to be fixed. 

However, it's for the PSC to determine if an RFC is necessary, so that means Orest, Greg, Jason, Jackie and Haris.

Traian

> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Dan Stoica
> Sent: Tuesday, November 02, 2010 10:53 PM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] Dropping off PSC
> 
> Hi,
> 
> Regarding the SHP provider, the decimals issue can be easily fixed. I
> recall there is a defect already filed but I didn't see it assigned. Do
> we need a RFC for this fix?
> 
> Dan.
> 
> -----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
> _______________________________________________
> 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