[gdal-dev] Call for discussion on RFC 50: OGR field subtypes

[Pepijn Van Eeckhoudt]

Hi Even,

For geopackage specifically, enumerations and ranges for primitive values can be encoded in gpkg_data_columns. These may or may not be enforced by check constraints, so it’s informative information. The idea is to make it easy for code to extract that meta information rather than having to parse and interpret SQL expressions.

Pepijn

> On 20 Nov 2014, at 14:38, Even Rouault <even.rouault at spatialys.com> wrote:
> 
> Hi Dmitriy,
> 
>> And what about string list field subtype?
>> I.e. I need restricted String field to accept only predefined strings
>> from the list?
> 
> That could potentially be modeled with a OFSTEnumeration subtype, and an extra 
> member variable of OGRFieldDefn with the list of accepted strings. A similar 
> idea could be used to model coded values, OFSTCodedEnumeration? + a map, found 
> for example in some FileGDB tables, as explained recently in 
> http://trac.osgeo.org/gdal/ticket/5741. 
> 
>> Also for integer or dates fields the value range(s) or time period(s)
>> set will be worth adding. I.e. the tube_width (Integer) can only be in
>> range 100-183 and etc.
> 
> I'm not sure how drivers would get those constraints though ? From SQL CHECK 
> constraints ?  Or would it be something that would be set by the application ?
> 
>> And finally I think the default field value is the subtype
>> responsibility too.
> 
> Not sure what you mean. There's already an embryonic default field value 
> mechanism, but AFAIK, it is not used anywhere in the code base except in 
> ogrfielddefn.cpp, and there's this comment whose rationale I don't have 
> knowledge above.
> 
> /**
> * \brief Set default field value.
> *
> * Currently use of OGRFieldDefn "defaults" is discouraged.  This feature
> * may be fleshed out in the future.
> *
> */
> 
> void OGRFieldDefn::SetDefault( const OGRField * puDefaultIn )
> 
> 
> Anyway, I believe there's potential for further enhancements in that area, but 
> I'd like to keep this RFC focused on the subtypes already mentionned in it.
> 
> Best regards,
> 
> Even
> 
>> 
>> Best regards,
>>     Dmitry
>> 
>> 20.11.2014 01:14, Even Rouault пишет:
>>> Hi,
>>> 
>>> This is a call for discussion on RFC 50: OGR field subtypes
>>> 
>>> http://trac.osgeo.org/gdal/wiki/rfc50_ogr_field_subtype
>>> 
>>> Below the summary :
>>> """
>>> This RFC aims at adding the capability of specifying sub-types to OGR
>>> fields, like boolean, 16 bit integers or 32 bit floating point values.
>>> The sub-type of a field definition is an additional attribute that
>>> specifies a hint or a restriction to the main type. The subtype can be
>>> used by applications and drivers that know how to handle it, and can
>>> generally be safely ignored by applications and drivers that do not.
>>> """
>>> 
>>> Even
>> 
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4151 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20141120/f7eacb5a/attachment.bin>