[fdo-internals] Dropping off PSC

Greg Boone greg.boone at autodesk.com
Wed Nov 3 16:28:06 EDT 2010 

Fair enough, but I have just seen too many 'if ("SHP")' code paths not to be wary.

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 2:53 PM
To: 'FDO Internals Mail List'
Subject: RE: [fdo-internals] Dropping off PSC

Hi Greg,

What you bring up would only be relevant for a hypothetical application which deals exclusively with Decimal type and cannot handle FDO integer types. I don't think such an FDO application exists.

There are no workarounds to remove either since Decimal currently uses GetDouble to get the value and it would imply removing support for the Double data type if we remove any of the Decimal handling code.

Traian


> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Greg Boone
> Sent: Wednesday, November 03, 2010 11:44 AM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] Dropping off PSC
> 
> 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
> _______________________________________________
> 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

More information about the fdo-internals mailing list