[fdo-internals] Dropping off PSC

[Haris Kurtagic]

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
>